Příspěvky

466

Windows a jiné systémy / Re:Linux a v něm běžící virtuál s Windows

« kdy: 02. 01. 2020, 18:14:00 »

Rychlosti SPICE jsem myslel spusteni qemu-system-... s grafickym oknem (to predpokladam pres SPICE nebezi) a potom SPICE klienta.

Jak jsem psal, nikdy jsem si nevšiml nějaké rozdílu v rychlosti reakce GUI qemu okna vs. spice klienta. Qemu-okno je moc jednoduché takže je lepší Spice klient, který nabízí např. funkce USB-redir přímo z menu. Když vypneš Spice klienta, tak ti VM stále běží, ale když vypneš Qemu-okno, tak se VM natvrdo killne.

Při použití virt-managera se VM neukončuje, lze se opět připojit a VM zobrazit v původním stavu.

Qemu-oknem nebylo myšleno spuštění VM za použití virt-managera, ale přímé spuštění Qemu z příkazové řádky (qemu-system-x86_64 -daemonize -enable-kvm ...), tzn. zcela bez libvirtu a bez virt-managera. Tam to opravdu funguje tak, že když když Qemu-okno zavřeš, tak tím ukončíš celou VM a to i v případě, že Qemu spouštíš s parametrem "-daemonize". U mě se to tak chová.

Doporučuju si to celou virtualizaci vyzkoušet pomocí virt-managera, je to univerzální nástroj nejen pro qemu-kvm a to GUI dá poměrně dobrou představu o možnostech (i když není zas tak úplně intuitivní).

Souhlasím a pokud by chtěl později VM spouštět bez virt-managera, tak lze použít ovládání přes CLI (virsh) nebo po spuštění přes virt-managera (nebo virsh) lze z běžících procesů zjistit přímo parametry pro Qemu (qemu-system-x86_64 -daemonize -enable-kvm ...). A pak by mohl spouštět čisté Qemu bez Libvirtu. To už je na vkusu každého sůdruha. 

467

Windows a jiné systémy / Re:Linux a v něm běžící virtuál s Windows

« kdy: 02. 01. 2020, 16:21:36 »

Rychlosti SPICE jsem myslel spusteni qemu-system-... s grafickym oknem (to predpokladam pres SPICE nebezi) a potom SPICE klienta.

Jak jsem psal, nikdy jsem si nevšiml nějaké rozdílu v rychlosti reakce GUI qemu okna vs. spice klienta. Qemu-okno je moc jednoduché takže je lepší Spice klient, který nabízí např. funkce USB-redir přímo z menu. Když vypneš Spice klienta, tak ti VM stále běží, ale když vypneš Qemu-okno, tak se VM natvrdo killne.

468

Windows a jiné systémy / Re:Linux a v něm běžící virtuál s Windows

« kdy: 02. 01. 2020, 16:09:22 »

aby po loginu nabehly na 2. desktopu ty Windows do fullscreenu ?

Spuštění programu na specifické pracovní ploše - https://forum.xfce.org/viewtopic.php?id=3124
Na spuštění do fullscreenu je většinou nějaký parametr programu který ti bude zobrazovat GUI virtuálky. Třeba u Remote-vieweru je to parametr "-f" - https://www.systutorials.com/docs/linux/man/1-remote-viewer/ . Pokud budeš používat libvirt a virt-manager, tak tam asi taky bude nějaké nastavení, aby se VM při startu spustila na fullscreen.

A pri shutdownu se virtualni masina nejak uspala ?

Ano lze to. Dělá se to pomocí systemd - https://wiki.archlinux.org/index.php/QEMU#With_systemd_service
Já to mám pomocí jednorázové služby systemd, ale to si už upravíš podle sebe. V podstatě jde jen o to, že se ti při vypínání linuxu do VM pošle příkaz "system_powerdown" a ve VM ve Windowsu si můžeš někde v ovládacích panelech nastavit, že při stisknutí tlačítka "vypnutí" se Windows nevypne, ale uspí (na disk). Při spuštění linuxu a následně spuštění VM můžeš pokračovat v práci. Problém je pouze v tom, že když se ti zaktualizuje Qemu, tak Windows to vyhodnotí jako novou konfiguraci PC a místo probuzení ze spánku ti nabootuje do čistého startu. Takže musíš před aktualizací Qemu vše ve Win uložit, normálně ho vypnout a až pak zaktualizovat Qemu.

469

Windows a jiné systémy / Re:Linux a v něm běžící virtuál s Windows

« kdy: 02. 01. 2020, 13:58:47 »

V XFCE je skvělá věc, že se lze přepnout na vedlejší plochu pouze tažením myši přes okraj obrazovky. Problém je když člověk potřebuje 3D aplikaci ve které se musí "otáčet" myší, ale pokud takové aplikace nevyužívá, tak je to asi ten nejrychlejší a nejpohodlnější způsob přepínání mezi Linuxem a virtuálem Windowsu.

Jake je zpomaleni Windows (pocitove nebo benchmarkem) kdyz bezi v KVM ?

Pokud máš SSD a tvůj CPU není úplný šmed, tak si myslím, že pocitově nepoznáš rozdíl mezi železem a VM.

A jake je zpomaleni GUI pres SPICE vs. bezi v okne ?

Moc nevím jak to myslíš. SPICE je protokol. Vidět GUI virtuálky můžeš pomocí více programů, které využívají SPICE. Nejznámější je asi Remote-viewer (což by měla být odnoš programu, který je vestavěn ve virt-manageru). Program využívající SPICE můžeš vidět na fullscreen i v okně. Nikdy jsem si nevšiml, že by to v okně běželo pomaleji, víc jde o to, že když to hodíš z fullscreenu do okna, tak už nemusíš mít pixel na pixel a bude to trochu mázlé. Pokud tím "běží v okně" myslíš "běžení v Qemu okně (bez SPICE)", tak rozdíl nepoznáš (já jsem ho teda nepoznal).

470

/dev/null / Re:Těžké OOP problémy

« kdy: 12. 11. 2019, 19:13:02 »

Bude to založeno na principu Schrödingerovy kočky doplněné o podmínku, že se krabice nesmí nikdy otevřít, tedy bude platit že Bůh dokáže vyrábět neuzvednutelný kámen a zároveň ho zvedat najednou. Zákaz otevření je tam pro trvalou superpozici obou stavů, při otevření by došlo k ukončení "víry" a byla by nahrazena věděním.

+1. Sice bezvýznamný off-topic, ale zároveň největší filozofické moudro na posledních 10 stranách této diskuze.

471

Hardware / Re:Raspberry pi4 +TV had + KODI = set-top box ?

« kdy: 08. 11. 2019, 18:32:10 »

Pánům Hitterekovi, Caletkovi a Pavoukovi 106 děkuji za po dlouhé době konečně hodnotné příspěvky k věci (na rozdíl od některých místních „znalců“).

A mně nepoděkovali Přitom jsem se opravdu hodně snažil popsat moje zkušenosti s Kodi. 

472

Hardware / Re:Raspberry pi4 +TV had + KODI = set-top box ?

« kdy: 07. 11. 2019, 13:24:50 »

Ved si mozes kupit riesenie za 20 Eur zapojit a nikdy viac neriesit tak preco RPI a hat a co je viem co este?

NAS + TV je jedna skatulka od dodavatela internetu. Ma to 2T disk takze pohoda a popravde nahravanie som pouzil asi 3x inak ide vsetko streamom alebo live tv. Ak ma niekto zaujem prehravat nieco s mobilu tak som tam pichol google chrome a mam uz rok pokoj. Lacne rychle bez nakladov na udrzbu. Inak do kody pohode streamujes prakticky hocico s hocikade takze velmi vela toho odpada.

Nějak jsem to nepochopil. Ty máš obyčejný DVB-T2 set-top-box za 20 € nebo IPTV set-top-box (např. od O2) za 20 €?

Ak ma niekto zaujem prehravat nieco s mobilu tak som tam pichol google chrome a mam uz rok pokoj.

Kam si ten Chrome pichol? Do RPi? Takže máš k TV připojený set-top-box, který slouží i jako NAS a přes druhý HDMI kabel napojené RPi? Takhle jsem to taky uvažoval, ale to přepínání vstupu na TV jsem nechtěl.

473

Hardware / Re:Raspberry pi4 +TV had + KODI = set-top box ?

« kdy: 07. 11. 2019, 10:52:06 »

Musíš, ale počítat s tím, že ti nějaký doplněk občas přestane fungovat. Někdy to tvůrce opraví za pár dnů a někdy nikdy

Příklad za všechny: doplněk Abradio je stále v oficiálních repozitářích Kodi https://kodi.wiki/view/Add-on:Abradio.cz přitom už mnoho let tento doplněk nefunguje.

Další problém co jsem s Kodi měl:
- pokud první zapneš zařízení s Kodi a nebudeš mít zaplou TV, tak se v Kodi načte výchozí rozlišení a po zapnutí TV se již neopraví. Musel jsem si udělat script, který před spuštěním Kodi čeká na zapnutí TV, protože jsem nevěděl jak změnit rozlišení Kodi za běhu.
- problém se skinem Titan. Nefungovaly tam nějaké tlačítka. Tvůrce to za pár dní po nahlášení opravil.
- Kodi se občas resetuje když je TVheadent server na stejném zařízení jako Kodi.

Nemám RPi, ale x86 NUC s LibreElec, ale výše uvedené problémy budeš mít i na RPi (možná kromě toho posledního).

Tím tě nechci od Kodi odradit, je to většinou lepší varianta než obyčejným set-top-box, ale musíš počítat s tím, že doplňky v Kodi ti nebudou fungovat vždy na 100%.

Ještě jsem si vzpomněl, že jsem měl problémy s Chromiem v Kodi na LibreElecu. Pokud bys chtěl Chrome/Chromium na RPi, tak musíš nainstalovat Raspbian a do něj Kodi+Chromium, protože v ostatních OS ( např. Libreelec) Chromium vůbec není, pokud se tedy něco nezměnilo.

K tomu tuner za cca $15.

Mám osobní zkušenost s porovnáním signálu z Avermedia Volar HD Pro vs. DVBSky T330 a tam kde Avermedia jel trhaně, tak DVBSky mělo obraz naprosto plynulý. Mám dojem, že o nízké citlivosti jsem četl i u XBOX TV Tuner, který byl opravdu za pár korun. Takže pokud někdo bydlí v místě se slabším signálem, tak vzít ten nejlevnější USB TV tuner nemusí být nejlepší volba.

474

Sítě / Re:Připojení DSL - kdo může za kvalitu připojení

« kdy: 26. 10. 2019, 12:00:10 »

Neměřili jste náhodou někdo množství výpadků DSL spojení na DSLAMu? Výpadkem DSL spojení mám na mysli, že vám zhasne kontrolka "DSL" a "Internet" a modem se začne znovu připojovat. Po 1-2 minutách zase vše bez problémů funguje.

Před časem jsem byl s ADSL napojen přímo na ústřednu a výpadky jsem nepozoroval. Teď jsem s VDSL na DSLAMu. Řesím nyní nějaké výpadky spojení a bylo mě technikem Cetinu řečeno, že tím, že je DSLAM "dálkově napájen" je méně spolehlivý než ústředna. U mě s modemem Comtrend mám cca 1 výpadek týdně a s modemem ZTE h267a cca 3 výpadky týdně. Domluvili jsme se, že ZTE vyreklamuji, protože na kabelech žádnou závadu nenašel, ale když se technik díval do logu výpadků toho DSLAMu, tak tam za jediný den byly snad 3 výpadky. Na dotaz proč mě nepřišla SMS o plánovaném výpadku říkal, že to byl "alarm" a asi tam byla nějaká porucha. Jestli někdo logujete výpadky internetu a víte, že jste na DSLAMu, tak by mě zajímalo jaká frekvence výpadků je u vás standardem. Dík.

475

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 17. 10. 2019, 11:50:00 »

Jenom bych upřesnil, že neustále píšete, že selhávají funkce flock() a file_put_contents() atd., ale ve skutečnosti selhává váš kód. Ty funkce fungují správně, chyby jsou ve vašem kódu.

Přesně tak. Já jsem myslel, že teď když si Exkalibr ten test doladil, že ho spustil celý znovu a všechny výsledky v grafu jsou SPOLEHLIVÉ zápisy dat, ale vypadá to, že se pořád plácáme v dolaďování testovacího scriptu. Jakýkoliv graf v tuhle chvíli ztrácí smysl. Jediná správná věc je všechno zahodit, napsat znovu test pečlivě (slovy pečlivě) a odprezentovat jediný graf s jasným sdělením. Takhle to vypadá, že cílem bylo pochlubit se uměním vytvářet grafy a testovací script posloužil jen jako generátor náhodných dat.

Blbost. Tady už není co dolaďovat napsal jsem snad jasně, že T10 je dokončený a bez chyb. Není co dolaďovat. K ostatním testům se vracet nebudu, nelze je opravit, když obsahují chyby. Jediné v čem se plácáme dokonala je tvá nechápavost. Psal jsem to už několikrát a nebaví mě to opakovat, že ten graf odráží rychlosti čtení a zápisu a chyby v tom nehrají roli. Když došlo k údajnému selhání fwrite, soubor byl přece načten a zkopírován pomocí copy(). Takže ty časy jsou spolehlivé a věruhodné. Nechápu co to tu furt plácáš.

To, že bych se v tom plácal já není nic překvapivého, tenhle test byl jeden velký chaos, jsi hodně zbrklý. Bohužel se v tom plácáš hlavně ty. Jestliže jsi napsal:

Ty testy jsem začal dělat proto, že jsem se chtěl bufferování vyhnout. Chtěl jsem najít způsob jak přečíst a zapsat data bezpečně do souboru, aniž bych se musel bát, že když je pozměním, změny nebudou uloženy. Proto mě ty funkce file_get(put)_contents nezajímají, jsou pro mě nepoužítelné.

tak to znamená, že jsi došel ke zcela mylnému závěru. Funkce file_get(put)_contents je spolehlivá a použitelná.

PS: psal jsem, že sem nebudu psát, protože jsem se bál, že rozjedeš diskuzi na téma toho nového zámku co jsi vymyslel.

476

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 17. 10. 2019, 09:49:54 »

Jenom bych upřesnil, že neustále píšete, že selhávají funkce flock() a file_put_contents() atd., ale ve skutečnosti selhává váš kód. Ty funkce fungují správně, chyby jsou ve vašem kódu.

Přesně tak. Já jsem myslel, že teď když si Exkalibr ten test doladil, že ho spustil celý znovu a všechny výsledky v grafu jsou SPOLEHLIVÉ zápisy dat, ale vypadá to, že se pořád plácáme v dolaďování testovacího scriptu. Jakýkoliv graf v tuhle chvíli ztrácí smysl. Jediná správná věc je všechno zahodit, napsat znovu test pečlivě (slovy pečlivě) a odprezentovat jediný graf s jasným sdělením. Takhle to vypadá, že cílem bylo pochlubit se uměním vytvářet grafy a testovací script posloužil jen jako generátor náhodných dat.

477

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 16. 10. 2019, 22:25:30 »

T3 a T4 - bufferování file_get_contents() a file_put_contents()

Ty testy jsem začal dělat proto, že jsem se chtěl bufferování vyhnout. Chtěl jsem najít způsob jak přečíst a zapsat data bezpečně do souboru, aniž bych se musel bát, že když je pozměním, změny nebudou uloženy. Proto mě ty funkce file_get(put)_contents nezajímají, jsou pro mě nepoužítelné.

No tohle je třeba jedna z věcí co nechápu. file_put_contents má parametr LOCK_EX, takže pokud to budeš mít dobře nastavené, tak se daný soubor zamkne a nic neselže. To, že se to bufferuje je právě výhoda, protože to je nejrychlejší a jak ti Kid hned na začátku diskuze vysvětlil, tak to buferování si hlídá filesystém a nevídím důvod proč bys tuto funkci neměl používat. Nebo místo parametru LOCK_EX můžeš použít mkdir.

478

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 16. 10. 2019, 20:34:50 »

Ty si přece u toho byl a sám si navrhl T8 @mkdir jako tu pojistku proti přepisům, vlastně si mi taky poradil jak odstranit tu chybu, že kontrola filesize je zbytečná a nespolehlivá.

No právě, byl jsem u toho a ani já se v tom nevyznám. Těch úprav, kódu, grafů a popisů chyb bylo tolik. Každého asi první budou zajímat ty nejrychlejší časy T3-T4 u kterých ses obával nespolehlivosti kvůli bufferování, tak jsem myslel, že to nějak okomentuješ.

Hlavní úspěch je především v tom, že se mi povedlo vyloučit ty selhání zápisu a selhání atomicity, takže T10 je první test s validními výsledky.

Jo i to, že všechny ostatní způsoby kromě T10 jsou špatné jsou výsledek. Pak ale nechápu k čemu jsou ty křivky T2-T8b v grafu když u nich dochází k selhání. K čemu je důležité znát rychlost v sekundách když při tom dochází k selhání?

Graf pak slouží hlavně pro orientaci v tom, že vidíš jaké jsou zdržení při zápisu na disk když běží 4 procesy ve smyčce bez prodlevy ... a potom jak se ten čas mění, když tam uměle strčíš prodlevu kvůli čekání na uvolnění directory lock.

A u kterých T je strčená ta prodleva? Možná jsi to psal na stackoverflow.com a možná je to někde na těch 10 stránách této diskuze. Mám dojem, že u T7 jsi psal o 50 microsekundové prodlevě o které jsi prohlásil, že nemá na měření vliv, ale teď myslíš asi jinou prodlevu.
Už je to jedno, jen jsem myslel, že když jsi tomu věnoval tolik času, že z toho uděláš nějaký výcuc, aby člověk mrkl na graf na popis pod ním a během minuty by pochopil o co jde.

479

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 16. 10. 2019, 18:32:14 »

@Exkalibr: Pokud k tomu grafu nemáš žádné vyhodnocení, tak proč si nám ho sem dal? K čemu nám je užitečný?

Proč by měl řešit, zda je nám ten graf k užitku? Zhodnotit si ho může každý, stejně jako ho každý může ignorovat dle své volby.

Ano, může si ho každý z nás zhodnotit tak, že bude 2 dny zkoumat zdrojáky a zjišťovat co v tom grafu vlastně je. Proč by tím měl trávit čas každý z nás když to může pár větami shrnout Exkalibr, který tomu ty 2 dny už věnoval.

480

Vývoj / Re:PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

« kdy: 16. 10. 2019, 17:39:18 »

@Exkalibr: Pokud k tomu grafu nemáš žádné vyhodnocení, tak proč si nám ho sem dal? K čemu nám je užitečný?