Fórum Ubuntu CZ/SK
Ubuntu pro osobní počítače => Multimédia => Téma založeno: Abby 18 Ledna 2020, 13:50:12
-
Zřejmě v souvislosti s tímto problémem - https://forum.ubuntu.cz/index.php/topic,84746.0.html jsem objevila ještě jeden problém a to že VLC mi nepřehrává obraz,ovládací prvky se "klonují" a jdou za sebou, zvuk jde normálně, obraz neběží. Na druhém monitoru (1080 20") je to v pořádku. Když ten druhý monitor odpojím tak to jde v pořádku i na primárním (4k 40"). Zkusila jsem VLC přeinstalovat, nepomohlo. Vymazala jsem nastavení, nepomohlo. Zkusila jsem betu, to funguje normálně, ale zase rozhraní je dost příšerné, zmatené a video se mi spustí v samotném okně a ovládání je v tom původním, takže tohle taky není řešení. Zkusila jsem i Kaffeine ale je tam stejný problém jako ve VLC. Zkusila jsem i odinstalovat Nvidia ovladače a po restartu je nainstalovat znova (z terminálu, fůůů :o ), ale nepomohlo to, s těmi to zřejmě nijak nesouvisí.
A také jsem zjistila, že mi v Boinc zmizela GPU, normálně Boinc počítal na GPU a teď ji nevidí. Něco se muselo asi rozbít při nějaké aktualizaci, ale těžko už dohledám při jaké :(
Máte někdo nějaké řešení nebo bude rychlejší čistá instalace a začít od začátku?
-
Tak jsem zkusila jinou distribuci - KDE Neon a je tam stejná chyba, takže chyba je zjevně někde v Linuxu resp. v kombinaci VLC, Linux a Nvidia ovladače takže asi nezbývá nic jiného než čekat až to někdo opraví, už aby to bylo protože se to takhle nedá používat.
-
Zkus VLC snap.
-
Vlc-nastroje-nastavenia-video
skus vybrat rucne "vystup", pripadne zvolit "zariadenie pre video zobrazovane na celu obrazovku".
-
Já už jsem na to možná přišla, jenom nevím jak to ověřit jestli je to správně. Jak můžu nainstalovat starší ovladače Nvidia a zakázat jejich aktualizaci? Jak totiž řeším vedle problém s Handbrake, tak mi nefunguje kódování když dám NVEnc ale když to dám normálně přes procesor, tak to jede. Takže právě podezírám ovladače Nvidie, že mají v současné verzi nějaký problém, mám 440.44.
-
Já už jsem na to možná přišla, jenom nevím jak to ověřit jestli je to správně. Jak můžu nainstalovat starší ovladače Nvidia a zakázat jejich aktualizaci? Jak totiž řeším vedle problém s Handbrake, tak mi nefunguje kódování když dám NVEnc ale když to dám normálně přes procesor, tak to jede. Takže právě podezírám ovladače Nvidie, že mají v současné verzi nějaký problém, mám 440.44.
Obecný postup:
1. Sehnat starší verzi.
2. Odinstalovat stávající verzi.
3. Nainstalovat starší verzi.
4. Uzamknout nainstalované balíky (v Synapticu) aby se neaktualizovaly.
U většiny balíků nabízí přímo Synaptic možnost "vynutit verzi" (je nabízeno více verzí, vybere se žádaná kterou je pak třeba opět uzamčít).
-
Zkusím to prozkoumat, díky.
Mimochodem, mezi odinstalací a reinstalací musí být restart nebo není nutný?
-
Zkusím to prozkoumat, díky.
Mimochodem, mezi odinstalací a reinstalací musí být restart nebo není nutný?
Restart rozhodně nic nepokazí, takže raději ano...
P.S. Netvrdil tu onehdá někdo (v jiném vlákně) jak rozběhat HW akceleraci grafikou pro H.265 rendering je jednoduchá záležitost?? :-\
-
Tak ve Windows i na Macu je to jednoduché, stačí si to vybrat a používat :) A v Linuxu mi to ještě před nedávnem fungovalo také, stačilo nainstalovat ovladače grafiky, nevím co se rozbilo a proč to nefunguje, ale během dneška jsem stihla vyzkoušet čtyři aktuální distribuce a nefunguje to v žádné z nich (Kubuntu 18.04.3, Ubuntu 18.04.3, KDE Neon, OpenSUSE Tumbleweed s KDE a Fedora 31 s Gnome). Ale jak mám zjistit, v čem je problém, když ve Windows to funguje normálně? A na Macu nemám Nvidii, tam to jede přes Intel GPU. Ve Windows aktualizuju ovladače GPU hned jak vyjdou a vždycky fungují bezproblémově, dokonce i s Boinc a navíc tam jsou novější - 441.87. Nevím, prostě mě napadá několik možností a u žádné vlastně nevím jak to ověřit a přiznám se že se mi ani nějak moc nechce to řešit, zbytečně ztrácet čas když potřebuju fungovat :( Doufám, že se to po nějaké aktualizaci zase rozběhne, protože u mě chyba zjevně není (viz čtyři čisté instalace různých distribucí a jedna dlouhodobě používaná).
-
Tak ve Windows i na Macu je to jednoduché, stačí si to vybrat a používat :) A v Linuxu mi to ještě před nedávnem fungovalo také, stačilo nainstalovat ovladače grafiky, nevím co se rozbilo a proč to nefunguje, ale během dneška jsem stihla vyzkoušet čtyři aktuální distribuce a nefunguje to v žádné z nich (Kubuntu 18.04.3, Ubuntu 18.04.3, KDE Neon, OpenSUSE Tumbleweed s KDE a Fedora 31 s Gnome). Ale jak mám zjistit, v čem je problém, když ve Windows to funguje normálně? A na Macu nemám Nvidii, tam to jede přes Intel GPU. Ve Windows aktualizuju ovladače GPU hned jak vyjdou a vždycky fungují bezproblémově, dokonce i s Boinc a navíc tam jsou novější - 441.87. Nevím, prostě mě napadá několik možností a u žádné vlastně nevím jak to ověřit a přiznám se že se mi ani nějak moc nechce to řešit, zbytečně ztrácet čas když potřebuju fungovat :( Doufám, že se to po nějaké aktualizaci zase rozběhne, protože u mě chyba zjevně není (viz čtyři čisté instalace různých distribucí a jedna dlouhodobě používaná).
No, malá nápověda - mám dojem, že to přímo souvisí s tímto (https://www.root.cz/zpravicky/vykonnostni-dopad-zaplaty-gpu-intel/)
případně s tímto (https://www.root.cz/zpravicky/intel-zaplatuje-bezpecnostni-diry-v-gpu-od-ivy-bridge-2012-po-coffee-lake-2017/)
A po žádné budoucí aktualizaci se to tím pádem rozhodně "nerozběhne"....
Jediná šance je udělat rollback na předchozí kernel (= ještě nepostižený tímto patchem) a uzamknout ho (= aby se neaktualizoval).
Protože vypnutí tohoto patche (bootovacím parametrem kernelu) zatím bohužel není možné...
Já sám to zatím řeším setrváním na posledním neopatchovaném kernelu, protože kvůli nějakému pofidernímu pocitu bezpečnosti (stejně se za chvíli zase objeví další "hrozba") se přeci dobrovolně nepřipravím o polovinu grafického výkonu.. :-\
Jo, a poslední "nepostižený" kernel je např. 5.0.0.37
A tu "jedovatou" záplatu na CVE-2019–14615 dostaly nyní všechny kernely vč. 18.04 LTS trojkového...
-
No, malá nápověda - mám dojem, že to přímo souvisí s tímto (https://www.root.cz/zpravicky/vykonnostni-dopad-zaplaty-gpu-intel/)
případně s tímto (https://www.root.cz/zpravicky/intel-zaplatuje-bezpecnostni-diry-v-gpu-od-ivy-bridge-2012-po-coffee-lake-2017/)
A po žádné budoucí aktualizaci se to tím pádem rozhodně "nerozběhne"....
Jediná šance je udělat rollback na předchozí kernel (= ještě nepostižený tímto patchem) a uzamknout ho (= aby se neaktualizoval).
Protože vypnutí tohoto patche (bootovacím parametrem kernelu) zatím bohužel není možné...
Já sám to zatím řeším setrváním na posledním neopatchovaném kernelu, protože kvůli nějakému pofidernímu pocitu bezpečnosti (stejně se za chvíli zase objeví další "hrozba") se přeci dobrovolně nepřipravím o polovinu grafického výkonu.. :-\
Může mi to dělat i přesto, že mám AMD Ryzen a Nvidia RTX? Prosím prosím, jak se vrátím na "nepostižený" kernel a hlavně který to je :) ? A co do budoucna, to už ten problém zůstane navždy nebo se to nějak podaří vyřešit aby to fungovalo?
BTW což mě napadá, že bych asi měla zkusit jak to funguje na notebooku, je to starý střep, HP650 s Pentiem a nějakou Intel GPU a tam Handbrake fakt nepoužívám, ale bylo by zajímavé zjistit jestli ho to postihlo taky.
-
Který "nepostižený" kernel je poslední píšu výše.
Vrátíš se na něj nejlépe rollbackem (pomocí Timeshift) (= obnovit systém do prosince 2019) a zamknout (v Synapticu) aktualizace kernelu (= přísl. metabalíky, jsou dva)).
Jinak libovolný kernel je možno si nainstalovat z mainline https://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D
Buď stáhnout/nainstalovat přísl. balíky ručně, nebo pro méně zdatné, k témuž využít aplikaci UKUU (ale starší verzi (https://github.com/teejee2008/ukuu/releases/download/v18.5.1/ukuu-v18.5.1-amd64.deb) - nová už není bohužel zdarma...).
A "přepnout" na něj při rebootu.
Nepotřebné kernely je možno odinstalovat.
Ryzenu by se to snad týkat nemělo - ale vyzkoušet to nemám jak.
Starých intelů by se to možná taky týkat nemělo, ale to jenom hádám...
Nicméně jsem na 90% přesvědčený, že tvůj momentální problém se týká právě této záležitosti. Jediné rozumné řešení je vrátit se na poslední nezáplatovaný kernel (5.0.0.37) (a zamknout ho).
Pokud se časem objeví bootovací přepínač (parametr) kterým se dá výše zmíněná záplata "vypnout", pak ho prostě použiješ.
Tím pádem můžeš uzamčení kernelu zrušit a jet na kernelech nových, které budou ovšem bootovat s přísl. parametrem a nedojde tak k degradaci výkonu grafiky. :)
Bootovací parametry kernelu se vkládají do souboru /etc/default/grub
buď přímo (pomocí txt editoru)
nebo to samé lze "naklikat" např. pomocí aplikace "Grub Customizer" viz obrázek (tam vidíš moje současné bootovací parametry kernelu).
Mám vypnuté všechny ty meltdown/spectre blbosti které snižují výkon CPU (Intel).
Až vyjde přepínač na CVE-2019–14615, s radostí ho tam přidám.
Do té doby prostě "vydržím na nezáplatovaném" kernelu. Taková (a bude stále hůř) ztráta výkonu je pro mě prostě nepřípustná.
Vše si poctivě zálohuji a proto se žádného ransomware nebojím, ano, už jsem měl tu čest se s ním setkat. A právě obnova dat ze zálohy to beze zbytku vyřešila. Veškeré zálohy mám vícenásobné, na sobě nezávislé a samozřejmě všechny offline...
Počítače s důležitým obsahem vůbec nesmí na internet - nikdy, to je základ.
A počítače které na internet smí, na těch jsou jenom "hlouposti" - prohlížeč, pár filmů, nějaká muzika, obrázky, něco o počasí, facebook atd.
Tam ať si každý zkoumá co chce, když ho to baví... :)
-
Díky, zkusím to, snad se to podaří.
Já jsem právě v létě ještě slušně prodala svou i5 i s deskou a přešla jsem na Ryzen 5 3600 a ani trochu nelituju. Ještě by mohlo AMD máknout na grafikách, je to dost tragédie...
-
Díky, zkusím to, snad se to podaří.
Já jsem právě v létě ještě slušně prodala svou i5 i s deskou a přešla jsem na Ryzen 5 3600 a ani trochu nelituju. Ještě by mohlo AMD máknout na grafikách, je to dost tragédie...
No podařit se to přece musí, když to předtím fungovalo...
A příčina "nefungování" nějaká určitě existuje.
----------------------------------------------------------------------------------------------------
Právě k tomu je ideální možnost rollbacku - člověk nemusí nic pracně hledat/zkoumat/řešit, zkrátka vrátí systém v čase zpět do konkrétního bodu a opět vše funguje (pokud to fungovalo předtím..).
Je sice možné, že následné kroky/aktualizace to pak celé znova "rozboří", ale opět tu zůstává možnost vrátit se (zpět) do daného bodu v čase (ten se rollbackem nezničí) a postup (třeba i mnohokrát) opakovat, či zvolit jiné body obnovy...
To je pro nováčky doslova "výhra v loterii". Nemusí se totiž bát experimentovat/zkoušet nové věci, jelikož vědí, že i když něco (i fatálně) pokazí, mají vždycky tzv. "krytá záda". Pověstný Damoklův meč reinstalace po každé sebemenší chybě se prostě nekoná... ;)
-
Právě k tomu je ideální možnost rollbacku - člověk nemusí nic pracně hledat/zkoumat/řešit, zkrátka vrátí systém v čase zpět do konkrétního bodu a opět vše funguje (pokud to fungovalo předtím..).
Je sice možné, že následné kroky/aktualizace to pak celé znova "rozboří", ale opět tu zůstává možnost vrátit se (zpět) do daného bodu v čase (ten se rollbackem nezničí) a postup (třeba i mnohokrát) opakovat, či zvolit jiné body obnovy...
To je pro nováčky doslova "výhra v loterii". Nemusí se totiž bát experimentovat/zkoušet nové věci, jelikož vědí, že i když něco (i fatálně) pokazí, mají vždycky tzv. "krytá záda". Pověstný Damoklův meč reinstalace po každé sebemenší chybě se prostě nekoná... ;)
S tím rozhodně souhlasím, akorát těžko zjišťovat odkdy to nefunguje...
-
Desi me, ze podle toho, co zde pisete, tak se nejedna jen o snizeni vykonu, ale se udelal patch jadra, ktery primo znemoznuje vyuziti akceleraci GPU pro encoding. Tedy jednu ze zasadnich vyhod. To je bud nepovedeny patch, ktery by opravit meli nebo nebetycna blbost tvurcu toho patche. Vubec mi to prijde, ze Linux misto aby byl rok od roku pouzitelnejsi, tak v nem od 14.04 funguje mene a mene veci a ty co jeste funguji, tak ne uz uplne nebo z velikym usilim je rozchodit. A jak se dozvidam z predikce zkuseneho Juwa, tak se objevuji veci, kterym nedava nadeji na opravu ... To mi vhani slzu do oka.
-
Desi me, ze podle toho, co zde pisete, tak se nejedna jen o snizeni vykonu, ale se udelal patch jadra, ktery primo znemoznuje vyuziti akceleraci GPU pro encoding. Tedy jednu ze zasadnich vyhod. To je bud nepovedeny patch, ktery by opravit meli nebo nebetycna blbost tvurcu toho patche. Vubec mi to prijde, ze Linux misto aby byl rok od roku pouzitelnejsi, tak v nem od 14.04 funguje mene a mene veci a ty co jeste funguji, tak ne uz uplne nebo z velikym usilim je rozchodit. A jak se dozvidam z predikce zkuseneho Juwa, tak se objevuji veci, kterym nedava nadeji na opravu ... To mi vhani slzu do oka.
Na novém HW je prý dopad toho patche minimální. https://www.phoronix.com/scan.php?page=article&item=intel-gen7-hit&num=1
Jinak tato přehnaná honba za bezpečností za každou cenu až do nefunkčnosti mě děsí.... :(
Osobně mám všechny tyhle nesmysly povypínané. Ten poslední vypnout nejde (zatím), proto zůstávám na 5.0.0.37 kernelu.
Dobrý přehled o tom co je/není vypnuté poskytne https://github.com/speed47/spectre-meltdown-checker
-
Mám nový HW a rozhodně se nedá říct, že by dopad byl minimální, nefunguje mi ani obyčejné přehrávání videa, nefunguje kódování v Handbrake a nefungují výpočty přes GPU v Boinc - oprava, výpočty už fungují, nemám nejmenší tušení proč, ale najednou to samo od sebe začalo vidět GPU. A to je jenom to co vím, kdoví kolik toho nefunguje co nevím. Navíc fakt nechápu proč by opravy pro Intel měly postihnout ty, co mají AMD, mám AMD Ryzen 5 3600, deska MSI B450 Tomahawk Max, RTX 2060, SSD Crucial MX 300 M.2 (a pro Windows ještě další SSD NVMe 1 TB a tak), zvukovka SB Audigy RX a 32 GB DDR4, rozhodně se tedy nedá říct, že by to byl nějaký starý šunt. Ale jestli to fakt způsobila nějaká pitomá záplata pro Intel, tak to mám teda fakt radost :( Proč mám být bita za neschopnost Intelu? Fakt doufám že to bude zase normálně fungovat, protože teď vlastně nemůžu počítač s Linuxem vůbec používat, i když mi fungují pracovní věci tak si k práci pouštím videa na druhém monitoru a ty nefungují. Odpojit druhý monitor není řešení i když to pak fungovat začne (na Handbrake to ale vliv nemá).
Jinak jsem nainstalovala jádro 5.0.0.37, teď na něm PC běží a výsledek viz screenshot :(
-
Zkus tohle https://www.appimagehub.com/p/1231861/startdownload?file_id=1530102655&file_name=VLC_media_player-x86_64.AppImage&file_type=application/x-executable&file_size=132537712
-
Je pravda - a to me velmi velmi prekvapilo - jsem instaloval Xubu 18.04 na HP EB 745 G2, kde neni od Intelu ani wifi ani prd a kdyz jsem projizdel nabidnute aktualizace, tak mezi nimi byl i Intel microcode a nejaky Intel neco (asi nejaky patch) - pro Boha k cemu a proc ?!!
Jinak Juwa poprosim, jestli by jsi treba do sekce pro tipy nedal nejaky soupis/strucny navod jak, kde u ceho povypinat jake patche? A jak je zase zapnout. To by nejspis vyuzilo vic lidi, kteri treba enkoduji apod. - proste je pro ne vykon dulezity.
-
Tak pánové, už jsem na to přišla a nebudete věřit tomu, co tenhle problém s VLC způsobuje. Vyzkoušela jsem jak nejnovější kernel tak doporučený 5.0.0.37 a nic, žádná změna. Vyzkoušela jsem starší ovladače 430, nic, žádná změna. Nainstalovala jsem úplně čistý KDE Neon (který si už asi nechám), aktualizovala a VLC prostě na primárním 4k monitoru nefunguje. Na sekundárním 1080 funguje normálně. Když odpojím sekundární monitor tak také funguje. Nakonec mě napadlo zkusit změnit škálování na 1.0 (normálně používám 1.7 při rozlišení 3840x2160). No a tady je ten zakopaný pes, při škálování 1.0 VLC funguje normálně. Akorát teda je všechno hrozně maličké, proto také používám škálování na 1.7 a je to jeden z důvodů, proč používám KDE, protože v Gnome je možné nastavit jen 100% a 200% a nic mezi...
Takže, co způsobuje problém je nalezeno, mám teď jádro 5.3.0-26, ovladače 435.21 (tedy to nejnovější co Neon nabízí) a při škálování 1.0 to funguje bez nejmenšího problému. Když ale dám pro mě pohodlné škálování 1.7 tak je problém zpátky (stejné škálování používám i ve Windows, je to pro mě optimální velikost). Co s tím? Napadá vás něco? Tedy kromě toho že si pořídím lupu :D
-
Je pravda - a to me velmi velmi prekvapilo - jsem instaloval Xubu 18.04 na HP EB 745 G2, kde neni od Intelu ani wifi ani prd a kdyz jsem projizdel nabidnute aktualizace, tak mezi nimi byl i Intel microcode a nejaky Intel neco (asi nejaky patch) - pro Boha k cemu a proc ?!!
Jinak Juwa poprosim, jestli by jsi treba do sekce pro tipy nedal nejaky soupis/strucny navod jak, kde u ceho povypinat jake patche? A jak je zase zapnout. To by nejspis vyuzilo vic lidi, kteri treba enkoduji apod. - proste je pro ne vykon dulezity.
Je to tak jednoduché, že není návod potřeba. Vypnutí spočívá v přidání příslušných bootovacích parametrů kernelu do souboru /etc/default/grub
Lze to taky (pohodlněji) udělat pomocí aplikace Grub Customizer.
Jednotlivé parametry jsou vždy oddělené mezerou:
pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier
Následně (po rebootu) lze ověřit co je/není vypnuté pomocí https://github.com/speed47/spectre-meltdown-checker
Patche se zpátky zapnou odstraněním oněch bootovacích parametrů a následným rebootem.
-
Tak pánové, už jsem na to přišla a nebudete věřit tomu, co tenhle problém s VLC způsobuje. Vyzkoušela jsem jak nejnovější kernel tak doporučený 5.0.0.37 a nic, žádná změna. Vyzkoušela jsem starší ovladače 430, nic, žádná změna. Nainstalovala jsem úplně čistý KDE Neon (který si už asi nechám), aktualizovala a VLC prostě na primárním 4k monitoru nefunguje. Na sekundárním 1080 funguje normálně. Když odpojím sekundární monitor tak také funguje. Nakonec mě napadlo zkusit změnit škálování na 1.0 (normálně používám 1.7 při rozlišení 3840x2160). No a tady je ten zakopaný pes, při škálování 1.0 VLC funguje normálně. Akorát teda je všechno hrozně maličké, proto také používám škálování na 1.7 a je to jeden z důvodů, proč používám KDE, protože v Gnome je možné nastavit jen 100% a 200% a nic mezi...
Takže, co způsobuje problém je nalezeno, mám teď jádro 5.3.0-26, ovladače 435.21 (tedy to nejnovější co Neon nabízí) a při škálování 1.0 to funguje bez nejmenšího problému. Když ale dám pro mě pohodlné škálování 1.7 tak je problém zpátky (stejné škálování používám i ve Windows, je to pro mě optimální velikost). Co s tím? Napadá vás něco? Tedy kromě toho že si pořídím lupu :D
A ten Handbrake už jede?
-
Je to tak jednoduché, že není návod potřeba. Vypnutí spočívá v přidání příslušných bootovacích parametrů kernelu do souboru /etc/default/grub
Lze to taky (pohodlněji) udělat pomocí aplikace Grub Customizer.
Jednotlivé parametry jsou vždy oddělené mezerou:
pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier
Následně (po rebootu) lze ověřit co je/není vypnuté pomocí https://github.com/speed47/spectre-meltdown-checker
Patche se zpátky zapnou odstraněním oněch bootovacích parametrů a následným rebootem.
Takže když mám AMD tak tam můžu dát bezpečně všechny tyto parametry a PC v ohrožení nebude? Jinak chtělo by to někam zapsat, já si to píšu do poznámek, ale aby to dohledali i ostatní...
A ten Handbrake už jede?
To momentálně nevím, šla jsem cvičit a pouštím si na mobílku filmy a protože momentálně nemám NAS (OMV ani jiny NAS OS pro PC nefunguje jak by měl a na výdaje má přednost auto, takže NAS bude, ale až někdy) tak sdílím disky z PC a z Linuxu to nemám zprovozněné (nevím jak, klikátko jsem na to nenašla, v OpenSUSE stačilo klepnout pravým myšítkem na složky a dát sdílet, ale v Neonu to není). Zjistím to za chvilku a dám vědět.
-
Tak Handbrake už také jede, akorát tam pro změnu zase nemám HE-AAC kodek... :/
Jinak nevím jestli to na nižším rozlišení bude ze screenshotu patrné, ale přikládám screenshot plochy jak to vypadá při škálování 1.0. Já na to prostě nevidím, nemám oči jako Sokolí oko a nedá se to takhle používat, je to prostě všechno hrozně moc malinké. Ještě přiložím pro porovnání screenshot okna Chromu, kde mám stránku zvětšenou na 175% a zbytek je systémově. Doufám že bude poznat jak to reálně vypadá i na nižším rozlišení. Akorát to musím nahrát někam jinam, je to moc velké a sem mi to nejde vložit.
https://i.imgur.com/Xqm7DHK.png
https://i.imgur.com/cwBeIdP.png
-
Takže když mám AMD tak tam můžu dát bezpečně všechny tyto parametry a PC v ohrožení nebude?
Ty uvedené bootovací parametry "vypínají" bezpečnostní patche (záplaty). Použije je ten, kdo dává přednost výkonu před "bezpečností".
Tyto bezpečnostní patche snižují (z principu) výkon HW. U staršího dokonce podstatně (viz testy na phoronix.com).
Proto je třeba si vybrat - buď bezpečnost, nebo výkon.
P.S. Je možno porovnat výkon PC s vypnutými/zapnutými záplatami.
Osvědčila se komprimace nějaké složky s mnoha soubory (10000+), např. profilu Chrome do archivu .7z Měří/porovná se čas potřebný k vytvoření archivu.
-
U toho Handbrake mi šlo o to, zda funguje GPU akcelerace při převodu.
Při tom škálování 1.7 je problém pouze u VLC?
Zkusilas ten VLC .AppImage? Nebo VLC snap?
-
Ty uvedené bootovací parametry "vypínají" bezpečnostní patche (záplaty). Použije je ten, kdo dává přednost výkonu před "bezpečností".
Tyto bezpečnostní patche snižují (z principu) výkon HW. U staršího dokonce podstatně (viz testy na phoronix.com).
Proto je třeba si vybrat - buď bezpečnost, nebo výkon.
P.S. Je možno porovnat výkon PC s vypnutými/zapnutými záplatami.
Osvědčila se komprimace nějaké složky s mnoha soubory (10000+), např. profilu Chrome do archivu .7z Měří/porovná se čas potřebný k vytvoření archivu.
No to chápu, ale není to odpověď na mojí otázku. Mám CPU AMD, které těmito chybami netrpí, to i kernel pro AMD má aplikované tyto opravy a snižuje to výkon i na AMD? Když dám ty parametry, tak se zvýší výkon i na AMD? A změní to nějak jeho bezpečnost, když AMD chybama Spectre, Meltdown atd netrpí?
U toho Handbrake mi šlo o to, zda funguje GPU akcelerace při převodu.
Při tom škálování 1.7 je problém pouze u VLC?
Zkusilas ten VLC .AppImage? Nebo VLC snap?
Co používám tak jsem našla problém jen u VLC. AppImage ani snap jsem nezkusila, zkusím to teda a dám vědět. Ale mám takový pocit, že Handbrake při škálování 1.7 také nefunguje, ještě to ověřím.
-
No to chápu, ale není to odpověď na mojí otázku. Mám CPU AMD, které těmito chybami netrpí, to i kernel pro AMD má aplikované tyto opravy a snižuje to výkon i na AMD? Když dám ty parametry, tak se zvýší výkon i na AMD? A změní to nějak jeho bezpečnost, když AMD chybama Spectre, Meltdown atd netrpí?
Neexistuje žádný "kernel pro AMD". Kernel je jenom jeden a má aplikované záplaty. Instaluje se na všechny PC stejný bez ohledu jaký je tam CPU.
Ano, AMD některými chybami netrpí, jinými ano. Intel je na tom hůře.
Dopad na výkon AMD - vyhledej si testy. Můžeš to taky orientačně posoudit viz výše.
Udělej si test pomocí toho checkeru (viz výše) a uvidíš...
Vypnutí záplat vždy bezpečnost sníží a výkon zvýší. Jde jen o to, o kolik (pro různá CPU a různé úlohy to bude různé).
P.S. Na Windows jdou ty záplaty zkontrolovat/vypnout taky pomocí https://www.grc.com/inspectre.htm
-
Aha, to jsem nevěděla. Jinak ten test bych si ráda udělala, ale obávám se že nevím co s tím, poslal jsi odkaz kde jsou nějaké soubory, nevím co s nima. Ale to je asi jedno, ty záplaty problém nezpůsobují tak je nechám radši aktivní.
Jinak Handbrake funguje i když nastavím škálování a VLC nefunguje při jakémkoliv škálování, od 1.1 nahoru. Zkusím tedy ten snap.
-
Tak zkusila jsem nejdřív AppImage a ten nefungoval vůbec, program se spustil, ale kousnul se a video nepřehrával. Tak jsem zkusila snap a ten funguje i se škálováním, takže to snad už bude ok. Jak ten snap vlastně funguje? Bude se to normálně aktualizovat jako když to bylo nainstalované přes Synaptic?
-
Jinak ten test bych si ráda udělala, ale obávám se že nevím co s tím, poslal jsi odkaz kde jsou nějaké soubory, nevím co s nima.
Stáhni si a v Terminálu spusť skript spectre-meltdown-checker.sh příkazem:
sudo sh "/cesta/ke/spectre-meltdown-checker.sh"
Výsledkem je takováto zpráva (je mnohem delší, na obrázku je vidět jenom začátek).
-
Tak zkusila jsem nejdřív AppImage a ten nefungoval vůbec, program se spustil, ale kousnul se a video nepřehrával. Tak jsem zkusila snap a ten funguje i se škálováním, takže to snad už bude ok. Jak ten snap vlastně funguje? Bude se to normálně aktualizovat jako když to bylo nainstalované přes Synaptic?
Ano, snapy se aktualizují automaticky. Poslední tři verze zůstávají, starší se mažou. Jediná nevýhoda je, že snapy zabírají dost místa (veškeré knihovny si táhnou s sebou). To VLC samotné má snad 1,5 GB...
-
Díky moc za obojí. Snap asi není špatná věc, ale mít v něm všechno tak nestačí asi ani terabajtový disk... Ale funguje to a to je hlavní :) A teď nastal čas na řešení dalšího problému, jdu založit vlákno :D (půjde to někdy bez problémů?)
-
Ještě mě (poněkud opožděně) napadlo - jedeš na X nebo na waylandu? (lze přepínat na logon screen). Protože grafický server by s tím mohl souviset (s tím jak se chová to škálování).
Na čem momentálně jedeš zjistíš příkazem
echo $XDG_SESSION_TYPE
-
abby@Daemon-Linux:~$ echo $XDG_SESSION_TYPE
x11
Nějak mě ani nenapadlo tohle řešit. Ale co jsem tak četla o Waylandu tak doufám, že tenhle nedodělek bude nejdřív dokončen než bude nasazen, spousta normálních věcí v tom prý nefunguje. Myšlenka je asi dobrá, ale provedení pokulhává.
-
T. J. jedeš na "X"....
Držs se od waylandu co nejdál - jak jen to půjde..
Nicméně zdejší komunitě dlužíš odpověď zda ten problém se škálováním se děje i na waylandu. Zkusit to není zase "tolik práce"....
-
Opravdu ma snap VLC 1,5GB? To je velikost celeho funkcniho operacniho systemu - to bych se bal mit na pocitaci - to musi umet spoustu veci, mozna i odecitat a odesilat vse, co uzivatel dela. Jinak nechapu, proc by prehravac mel mit takovou velikost. To proste bude nejake smecko urcite ...
-
Opravdu ma snap VLC 1,5GB? To je velikost celeho funkcniho operacniho systemu - to bych se bal mit na pocitaci - to musi umet spoustu veci, mozna i odecitat a odesilat vse, co uzivatel dela. Jinak nechapu, proc by prehravac mel mit takovou velikost. To proste bude nejake smecko urcite ...
Není, je to u snapu zcela běžná věc, flatpak je na to ještě hůř.
Příčina je ta, že zatímco normální VLC (má 30 MB) využívá systémové knihovny systému, ten snapový VLC si vše táhne s sebou, proto je tak obrovský. Na druhou stranu ale ke svému běhu nic (ze systému) nepotřebuje (žádné závislosti atd.).
VLC.AppImage má 126MB, po spuštění dojde k rozbalení do (/tmp), tam je toho pak pochopitelně víc...
-
1,5 GB snad nemaji ani vsechny knihovny v cerstve nainstalovanem systemu - proto mi to prijde podezrele. Jedine, ze by to bylo tak, aby to fungovalo na vsech verzich a bazich Linuxu - stejne na Ubuntu jako na Redhatu. Pak by to davalo smysl.
-
1,5 GB snad nemaji ani vsechny knihovny v cerstve nainstalovanem systemu - proto mi to prijde podezrele. Jedine, ze by to bylo tak, aby to fungovalo na vsech verzich a bazich Linuxu - stejne na Ubuntu jako na Redhatu. Pak by to davalo smysl.
Každý snap je v systému mountnutý jako virtuální disk. Nic ti nebrání prozkoumat jeho obsah (read only).
-
T. J. jedeš na "X"....
Držs se od waylandu co nejdál - jak jen to půjde..
Nicméně zdejší komunitě dlužíš odpověď zda ten problém se škálováním se děje i na waylandu. Zkusit to není zase "tolik práce"....
Já bych to i vyzkoušela, ale jak to mám udělat když už mám nainstalovanou snap verzi VLC která to nedělá? To mám snap verzi zase odinstalovat, nainstalovat normální VLC, přepnout na wayland, tam to vyzkoušet, přepnout zpět na x, odinstalovat normální VLC a nainstalovat snap verzi? No, možná to během dne zkusím :D
-
Nemusíš nic odinstalovávat. Verze VLC můžeš mít obě současně (tu snapovou i tu normální).
-
Aha no aspoň že tak. Vyzkouším to a dám vědět. Ale ještě si trochu postěžuju :(
Mám takový dojem že KDE Neon také nebude to pravé ořechové. Kromě toho že blbne škálování s VLC (což se teda podařilo vyřešit) tak nefunguje nastavení grub a teď jsem navíc zjistila že nefunguje "Správce diskových oddílů KDE", který používám pro trvalé připojení ostatních disků, vytvořím přípojný bod, dám uložit a ono to zapíše místo mě do /etc/fstab, ale v tomto případě ne, sice mi to napíše že to tam zapíše a že je to nevratné, ale nezapíše se nic... Sice by bylo řešení to prostě napsat ručně, ale proč bych to dělala když na to je pěkný a přehledný grafický nástroj. Ale ten v aktuálním Neonu prostě nefunguje :(
Je šance že se to brzo opraví? Má smysl zkoušet používat Neon? Mě se líbí že je tam nové KDE a tohle prostředí mám fakt ráda a třeba v Kubuntu je KDE dost osekané a musela jsem tam doinstalovat milion dalších věcí, tady je všechno potřebné. Ale jestli je to takhle polofunkční... Co případně místo Neonu aby to mělo nové KDE a fungovalo to? Aby to zkrátka nebyla dva roky stará vykopávka.
-
Hmmm, tak to na waylandu nevyzkouším i když snaha byla. Vybrala jsem na přihlašovací obrazovce "Plasma (Wayland)", přihlásila jsem se, zčernaly oba monitory a PC přestal na cokoliv reagovat, nefungovala ani kontrolka num lock, ani přepnutí do textového režimu, nefungovalo nic kromě vypnutí podržením zapínacího tlačítka. Naštěstí po novém spuštění mi naběhlo KDE normálně na X a zdá se že to běží dál.
V čem může být problém že se to takhle zachovalo? Příliš nový HW? Ovladače grafiky přímo od Nvidie a ne ty nefunkční open ****?
-
Vypadá to na ty drivery.
A ten Správce diskových oddílů KDE spouštíš s právy roota? Pokud ne, pak je logické, že se do fstab nic neuloží...
-
Tak to fakt nevyzkouším protože zbavovat se Nvidia ovladačů se mi fakt nechce, s Noevau nebo jak se to jmenuje to spíš nefunguje než ano.
Předpokládám že ano, protože to po mě při spuštění chce heslo. Ale nějak nevím jak spustit program s právy roota ručně, když zadám ALT+F2 a tam třeba kdesu kwrite tak mi to nabídne instalaci nějakého editoru a když to samé napíšu v konzoli tak mi to napíše "kdesu: příkaz nebyl nalezen", přitom kdesu bych měla mít nejspíš nainstalovaný (příloha). A když napíšu sudo kwrite tak mi to napíše nějakou hovadinu o bezpečnosti - "Executing KWrite with sudo is not possible due to unfixable security vulnerabilities."
Takže to co fungovalo dřív teď nefunguje a já nevím co s tím.
-
Grafické aplikace se nyní spouštějí s právy roota pomocí pkexec
Některé aplikace ale k tomu vyžadují přísl. soubor .policy ve složce
/usr/share/polkit-1/actions
Vytvořit soubor .policy pro nějakou aplikaci je snadné. Jako "mustr" lze použít některý ze stávajících. Zde je na ukázku tento soubor (/usr/share/polkit-1/actions/org.gnome.gedit.policy) pro gedit:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>
<vendor>Gedit</vendor>
<vendor_url>http://gnome.org/</vendor_url>
<icon_name>text-editor</icon_name>
<action id="org.gnome.gedit">
<description>Run Gedit as root</description>
<description xml:lang="cs">Spustit Gedit jako root</description>
<message>Authentication is required to run Gedit as root.</message>
<message xml:lang="cs">Pro spuštění aplikace Gedit jako root se vyžaduje autentizace.</message>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>auth_admin</allow_inactive>
<allow_active>auth_admin</allow_active>
</defaults>
<annotate key="org.freedesktop.policykit.exec.path">/usr/bin/gedit</annotate>
<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
</action>
</policyconfig>
Dříve se ke spouštění GUI aplikací s root právy používalo gksu (gksudo, kdesu). To je nyní už z dister vypuštěno. Nicméně se dá doinstalovat (použijí se dva balíčky z Artfull) a normálně funguje dál...
--------------------------------------------------------------------------------------------------------------
Takže napřed zjisti jakým příkazem se daná aplikace spouští (podívej se do spouštěče, je to soubor .desktop, otevři ho v txt editoru).
Příkaz je v řádku který začíná EXEC= Před příkaz dopiš pkexec a zkus to spustit. Pkexec funguje i při spouštění z Terminálu.
-
Děkuji, zkusila jsem ten KWrite a Dolphin a oba mi řekli následující a odmítli se spustit...
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: wayland-org.kde.kwin.qpa, eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.
Neúspěšně ukončen (SIGABRT)
Co s tím? Nemám nejmenší tušení co to po mě chce.
-
Tak u KDE aplikací, jak jsem nyní ke svému překvapení zjistil to takto jednoduše nefunguje - u ostatních ano.
Zkus to na základě tohoto článku (https://fitzcarraldoblog.wordpress.com/2019/09/19/how-to-run-kde-dolphin-kate-and-kwrite-as-root-user/) ještě takto:
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true dolphin
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true kwrite
Další postupy zde (https://askubuntu.com/questions/990611/how-to-run-dolphin-as-root) Ovšem tam už se jedná o editaci souborů v hexaeditoru....
-
Ježíšmarjá :o :o :o