OpenTofu, tj. svobodný a otevřený fork Terraformu vzniknuvší jako reakce na přelicencování Terraformu z MPL na BSL (Business Source License) společností HashiCorp, bylo vydáno ve verzi 1.7.0. Přehled novinek v aktualizované dokumentaci. Vypíchnout lze State encryption.
Spouštět webový prohlížeč jenom kvůli nákupu kávy? Nestačí ssh? Stačí: ssh terminal.shop (𝕏).
Yocto Project byl vydán ve verzi 5.0. Její kódové jméno je Scarthgap. Yocto Project usnadňuje vývoj vestavěných (embedded) linuxových systémů na míru konkrétním zařízením. Cílem projektu je nabídnou vývojářům vše potřebné. Jedná se o projekt Linux Foundation.
Operační systém 9front, fork operačního systému Plan 9, byl vydán v nové verzi "do not install" (pdf). Více o 9front v FQA.
Svobodná webová platforma pro sdílení a přehrávání videí PeerTube (Wikipedie) byla vydána v nové verzi 6.1. Přehled novinek i s náhledy v oficiálním oznámení a na GitHubu. Řešeny jsou také 2 bezpečnostní chyby.
Lennart Poettering na Mastodonu představil utilitu run0. Jedná se o alternativu k příkazu sudo založenou na systemd. Bude součástí systemd verze 256.
Hudební přehrávač Amarok byl vydán v nové major verzi 3.0 postavené na Qt5/KDE Frameworks 5. Předchozí verze 2.9.0 vyšla před 6 lety a byla postavená na Qt4. Portace Amaroku na Qt6/KDE Frameworks 6 by měla začít v následujících měsících.
Byla vydána nová verze 2.45.0 distribuovaného systému správy verzí Git. Přispělo 96 vývojářů, z toho 38 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání. Vypíchnout lze počáteční podporu repozitářů, ve kterých lze používat SHA-1 i SHA-256.
Před 25 lety, ve čtvrtek 29. dubna 1999, byla spuštěna služba "Úschovna".
Tento test byl proveden překladem jádra (výchozí konfigurace pro architekturu amd64). Jádro bylo přeloženo třikrát po sobě, každý překlad ze samostatné kopie zdrojových kódů. Na rozdíl od předchozího testu, který značně vytěžoval hlavně disky, je v tomto případě více využíván procesor a úložiště spíše okrajově.
Měřena byla doba běhu testu, tj. celková doba překladu ze tří kopií zdrojových kódů.
Test byl proveden na hostiteli a porovnáván s během na hostu KVM 1/1 a Xen 1/1.
Hostitel | KVM 1/1 | Xen 1/1 | |
---|---|---|---|
real | 24 m 19,559 s | 31 m 33,392 s (+29,7 %) | 27 m 6,909 s (+11,5 %) |
Na hostiteli byl proveden test sedmi paralelně běžících testovacích procesů, které byly omezeny na používání pouze sedmi CPU v systému. Výsledek byl porovnáván s během na hostech varianty 1/1.
Hostitel | KVM 1/1 | Xen 1/1 | |
---|---|---|---|
minimum | 30 m 10.0s | 34 m 5.1s (+13,0 %) | 27 m 56.3s (-7,4 %) |
průměr | 30 m 20.6s | 34 m 59.5s (+15,3 %) | 29 m 15.1s (-3,6 %) |
maximum | 30 m 29.5s | 35 m 19.7s (+15,9 %) | 29 m 42.6s (-2,6 %) |
Tento test byl míněn víceméně jako zátěžový, cílem bylo zjistit, jestli nedojde k pádu/zatuhnutí některého z hostů. Na hostiteli se netestovalo, testována byla varianta hostů 1/4.
KVM 1/4 | Xen 1/4 | |
---|---|---|
minimum | 136 m 58,057 s | 134 m 24,515 s |
průměr | 140 m 51,606 s | 135 m 9,248 s |
maximum | 143 m 32,285 s | 136 m 6,894 s |
Obdobně jako u podobného testu využívání CPU bylo spuštěno 19 testovacích procesů, z toho 16 na hostech 1/4 a 3 na hostech 1/1. Opět bylo cílem zjistit, jak dobře dokáží jednotlivá virtualizační řešení zajistit rozdíly ve výkonu, když je požadujeme.
KVM | Xen | |
---|---|---|
1/1 | 36 m 52,858 s | 34 m 17,063 s |
1/4 | 131 m 26,102 s | 121 m 8,294 s |
poměr | 3.563 | 3.533 |
V tomto testu při všech variantách vytížení podává KVM horší výkony než Xen – práce s diskem je zde sice okrajová, ale i tak dostatečně významná na to, aby výkon KVM utrpěl. Nejvýraznější rozdíl je u testu bez paralelizace, nejméně výrazný u velkého počtu naráz běžících překladů.
Poměrně překvapivý je výsledek Xenu při běhu sedmi překladů paralelně, kde byli hosté rychlejší než hostitel.
Při testu izolace mezi různými výkonnostními variantami se projevilo to, že Linux víceméně nemá žádný způsob4, jak dobře omezovat nebo dělit přístup k disku; omezování využívání CPU využívání disků přímo neovlivňuje. Xen si v tomto případě víceméně udržel svůj výsledek z minulého testu, KVM si pohoršilo a dostalo se na úroveň Xenu.
Test, který byl míněn jako zátěžový, hosté bez problémů zvládli.
4 V jádře 2.6.33 se objevila první vlaštovka, ale zatím se jedná pouze o první krok z mnoha.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
Ano, to je velice nepříjemná věc v debianu (u mě squeeze) - musí se instalovat balík "qemu-kvm", protože balíček "kvm" je VELICE a značně zastaralý, způsobuje výkonnostní anomálie, padání guestů, ...
Prvne diky moc za clanek.
Kdyby na to nekdy byla chut, tak bych moc rad videl aspon zakladni porovnani behu widli na Xen a KVMku. Sam jsem si hral s Win 2k3 serverem a na obojim se chova proti Linuxu mnohem hur. Na Xenu widle doslova staly na miste kvuli desivejm odezvam. Na KVM to bylo lepsi, ale zase se dost desne chovaly disky.
Lidi, jakou mate zkusenost s virtualizaci widli? Zaslech jsem, ze velmi dobre chodi vmware server, ale zrovna nemam volnej HW na testovani.
Protože se KVM poměrně rychle vyvíjí, byla použita verze z Debianu Unstable – v té době nejnovější jádro 2.6.31 (balík linux-image-2.6.31-1-amd64) a kvm-85 (85+dfsg-4.1).Opravdu bylo použito poslední KVM? kvm-85 je poměrně starý balík. Aby nedošlo ke zmatení čtenářů... Sám používám na desktopu unstable a používám balík qemu-kvm, teď ve verzi 0.12.3+dfsg-4. V dokumentaci se lze dočíst v
/usr/share/doc/qemu-kvm/changelog.upstream-kvm.gz
, že tento balík je založen na kvm-88 [12 july 2009]. Sám jsem používal chvíli kvm-85 a měl problémy s virtualizovanými Windoze. Po čase jsem si všiml balíku qemu-kvm (s novějším KVM). V tom mě Windoze běžely o řád lépe (to už je tak 3/4 rok zpět). Tedy nevím kdy tyhle testy proběhly, ale o aktuálnosti user-space části KVM lze dost pochybovat?
No a co se týče XENu, tak ten je teď samozřejmě v kernelu 2.6.32 připravován pro Squeeze také zřejmě v novější podobě.
Nechtěl by si někdo dát práci a ty testy zopakovat?
Opravdu bylo použito poslední KVM?V té době... je to cca půl roku, spíš víc, nechá se to odvodit i podle "nejnovějšího jádra" 2.6.31. Holt docela dlouho trvalo to sepsat.
qemu-kvm (0.11.0+dfsg-1) unstable; urgency=low * Package qemu-kvm (stable series) instead of kvm (snapshots) * Simplify the packaging, remove support for external module source * Move old debian/changelog to debian/changlog.kvm -- Jan Lübbe <jluebbe@debian.org> Mon, 02 Nov 2009 11:49:28 +0100Zrejme ty testy probehly jiz v roce 2009...
Bohuzel spatne dopadl test site a spousteni.Teď jsem ještě zkusil netperf -t TCP_STREAM mezi KVM Linux hostem (virtio síť) a fyzickým strojem (ne hostitelem) a vyšlo cca 920×10^6 b/s na gigové síťovce. Stejný fyzický stroj proti hostiteli dá 940, takže tu síť bych opravdu tak špatně neviděl. netperf AFAIK používají k benchmarkování i vývojáři jádra, takže špatným nástrojem to IMO taky nebude...
Zalostne taky dopadlo rekurzivni spousteni skriptu. Linux Host mel 1:25 (v minutach), XEN guest mel 1:34, windows xp host s cygwinem sam mel 20:31.Zatímco v Linuxu, jako ostatně ve většině unixů, jsou procesory "lehké" (light-weight) a jejich spouštění přes
fork()+exec()
relativně nenáročné, ve Windows jsou procesy relativně "těžkotonážní", fork()
není nativně v dispozici (Cygwin ho musí emulovat) a mnohem víc se využívají lehká vlákna. Pokud se na
Windows provozuje program silně používající unixový styl (např. právě ono rekurzivní spouštění skriptů), je logické, že výsledek dopadne takto žalostně.
Pamatuju si, jak jsem kdysi musel při portování jednoho svého programu z Linuxu na Windows přepsat volání externích utilit na používání knihoven, protože to, co Linuxu běžel celkem slušně, bylo ve Windows nepoužitelně pomalé - rozdíl v rychlostech byl téměř o řád a většinu zátěže spotřebovalo spouštění oněch externích utlilit (užívaných jako "filtry" na načítání vstupních a ukládání výstupních obrázků).
Tisk bez diskuzetak dostanes cely clanek...
Asi tolik ke slavne virtualizaci