Příspěvky

166

Windows a jiné systémy / Na disk zapisuje proces System, ačkoli stahuje youtube-dl.exe

« kdy: 19. 02. 2020, 20:00:38 »

program youtube-dl stahuje (přímo soubor http://neco.cz/neco.mp4 : "WARNING: URL could be a direct video link, returning it as such.") a ukládá na disk. Mám OS Win 7.
Nicméně resmon.exe hlásí, že youtube-dl nic nezapisuje na disk. Na disk zapisuje Proces System (konkrétní soubor c:\....)
Spustím li process explorer - u procesu vidím v Properties:
Disk and network: Disk io samé nuly,, Network-receive (-s, bytes, delta) odpovídá stahování.
Performance graph  IO writes 300kB/s na grafu
Performance -  I/O: tam zápis vidět je: write bytes delta (300kBps) - jen textová reprezentace odpovídající grafu výše


stejné Pro proces system: tam není žádná aktivita, ani network ,ani IO ani disk.

Obecné okno process exploreru (Ctrl I) System Info : network receive: 300kBps,, I/O 300kBps, ale Disk: nic


takže proč resmon přisuzuje zápis na disk pseudo procesu System
a proč tedy process explorer nevidí žádný zápis na disk (Disk write), ale vidí IO?

... spouštěl jsem i v režimu admina. Díval jsem se i na ostatní procesy (cmd.exe, conhost)

167

/dev/null / Podivné chování hlasové schránky - ihned v ní

« kdy: 19. 02. 2020, 19:35:42 »

Setkal jsem se s divným chování hlasové schránky (teď nesoudím, jestli lidé mající hlasovou schránku jsou v pořádku):
1. volal jsem Lacovi, vyzvánělo to 30s až minutu, následně jsem hovor byl přijat, ale skončil v hlasové schránce, po 10 jsem ukončil.
2. za 10s se Laco ozval, nicméně já to típl (abych mu  neplýtval kredit, sám mám hodně) a
3. ihned jsem mu volal zpět, nicméně hovor IHNED přijala hlasová schránka. Jak je to možné?




Jaké chování hlasové schránky běžné? Když někomu volám, že se ihned dovolám do hlasové schránky (obecně, bez ohledu na tento příklad), například, že si někde "nastaví záznamník při nepřítomnosti"? Může nějak telefon nějak konfigurovat hlasovou schránku (takové to nastavení Menu- Telefon - Hovory  - přesměrování, druhá linka, zpráva při obsazení, co nikdo moc nepoužívá)

168

/dev/null / Re:blesk.cz zatěžuje 100% jádra a ještě gpu

« kdy: 19. 02. 2020, 19:08:13 »

Tezili

To snad ne. Chtěl jsem napsat "seriózní weby", ale  pak jsem zabrzbil, prostě tyhle weby téměř nepoužívají ( ikdyž používají řadu svinstev, například asi je  je zač  https://www.blesk.cz/js/loader_spark.js nebo https://www.blesk.cz/ads.txt  -mimo jiné dobrý základ pro hosts.txt  , fingerprinting- zablokován fp.js, fp.min.js, fp2.js, fp2.min.js), to používají "seriálové" weby co parazitují na seriálech na jiném úložišti), rovněž podezřelí je  cncvideplayer-fp.js, 1MB javascript pro přehrávání videa? zabalen asi v 20 vrstvách eval... nicméně nic zde z toho není
 
Proto mi to vrtá hlavou, že i po dezinfekci webu je takto náročný, přece jen z 20 JS jich 15 se načítá, a tam je prostoru pro nějaké hnoje dost stále.

Rozbor Performance:

Summary
scripting 0%
render 75%
painting 0%
Other 20%
Idle 2%

Bottom Up:
Update layer tree 80ˇ%
recalc style 10%
hit test 3%



Kandidáti:
https://img.blesk.cz/css/blesk/dist/deploy-2.0/blesk.main.min.2a006175ec1bc1436a97e0d520d12515.css


... mohu se na to vykašlat, načítá se tam asi 12 CSS, z toho jich více způsobí toto vytizeni. navíc i když si deaktivuji jeden klíčový css, kdy to vypadá pak rozpadle, tak to stále vytěžuje..

Samozřejmě při deaktivaci všech css to neblbne... Zjistil jsem, že je tam nějaký dementní css využívající animation, co dělá nějaký gradient při chybějícím obrázků, ale proboha, jak je to zprasené, že to dokáže vytížit moderní cpu na 100%

EDIT:. stává se i v chrome:66, na jiném PC, task manager chrome hlásí cpu load 102%

AD - novinky: u mě dobrý, samozřejmě blokováno gemius.pl google-analytics.com  imedia.cz, stat.novinky.cz, login.novinky.cz (tím to asi nebude) ale dost tam mám js-démonů +js(abort-current-inline-script.js,kununu_mul) +js(addEventListener-defuser.js, /^(beforeunload)$/) především kvůli zabránění zaplavením reklamami, toto také mám vypozororováno, že bez této medicíny to zátěž nezpůsobuje (samozřejmě v režimu bez cookies, jinak by na mě vystříkla žumpa reklam)

čili chápu tvoji stížnost, prostě z nějakého divného důvodu to vytěžuje tobě, i když mě ne. Ale pro jistotu doporučuji, co jsem udělal já - F12- Performance a zjistit, co je příčinou - javascript, render atdd.

169

/dev/null / blesk.cz zatěžuje 100% jádra a ještě gpu

« kdy: 19. 02. 2020, 12:42:22 »

ne že bych snad tento web četl, ale jak je možné, že zatěžuje 100% času jádra? Browser chrome 53.  celkem 8W, takže i v tom solidně jede GPU.
Zablokovány domény 3. stran (bez toho je to jako jít po václaváku po setmění) - asi 20. Povoleno jen cncenter.cz a odsud se dokonce) nenačítají žádné skripty (zablokován sas.min.js$script),na blesk.cz zablokováno 5 skriptů.
Podobné je to na zive.cz, info.cz, digiarena.cz, ale pouze v případě, že článek obsahuje vložené video případně fotogalerii.

profiling: scripting  11%, ale neustále repainting atd...

nevíte čím to je? používá tento web nějaké náročné věci (kromě reklam, které mám naprosto všechny zablokované) z CSS/animací či nějaké neustálé pozicování boxů místo běžné position:sticky?

170

Software / Re:Chromium dává kouř paměťové kartě

« kdy: 17. 02. 2020, 19:53:37 »

Samozřejmě že tam mám chlazení - malý Al Blok. Teplota nepřesahuje 66°C v nejhorším  případě, například při sw přehrávání videa je 61°C  ;  k throttlingu kvuli undervoltage dochází i při libovolné teplotě, a k swapovacímu záseku dochází taký při libovolné teplotě, resp, když se to stane, teploty ani nemusí být 55°C. Jak význam asi tak chlazení asi pro mé problémy má?
Asi nakonec to SSD vyzkouším, i kdyby to měl být nevzhledný kus krámu propletený redukcemi a kabely, abych tam ten božský SSD dal. Třeba SSD bude to nejlepší, co RPI potká po přechodu na napájení z GPIO-
Zdroj dává 5.2V a nad 2A. při 1A vpohodě 5.1V. Jenže i po napájení přes GPIO a se něco ztratí v drátech a i když na gpio pinech je 5.05V, tak hlásí undervoltage.
Přetaktování už nemám, problému s undervoltage ubylo o 20% asi, ale stále jsou obtěžující.

A 4K nekomentuji, nejen že to neumí hardwarově, ale v chrome z nějakého důvodu nejde hardwarově akcelerované video jakéhokoli rozlišení, s tím bych potřeboval pomoc, aby to šlo přímo v chromium nebo nějakém  špecial browseru (ne playeru, na to je omxplayer
), který si rozumí s raspberry pi.

171

O serveru Root.cz / HTTP ERROR 500, nelze se přihlásit

« kdy: 17. 02. 2020, 12:53:47 »

Po dvanácté servery lupa atd, root, forum.root nefungovaly, hlásili mi HTTP ERROR 500. Něco se stalo sesession či cookie, po smazání to již šlo, jenže se nešlo přihlásit a opakovaně to po té dávalo Http Error 500. Před 11 to šlo. Musel jsem si znova zaregistrovat účet, systém se předtím tvářil že můj nick zde není registrovaný. Nedějou se tu nějaké pšíkusy? či odstávka klíčových serverů?

172

Software / Re:Chromium dává kouř paměťové kartě

« kdy: 17. 02. 2020, 11:18:36 »

mne sa osvedcil noscript. je to sice do ohnivej lisky ale mozno to ma aj chromium...

tak mit doplnky uBlockOrigin a PrivacyBadger povazuju za samozrejmost, ale to resi caste cteni/zapis cache uloziste jen castecne

To je samozřejmost, ale z jiného důvodu, že jinak je prohlížení webu na blití, vedlejší efekt (ačkoliv také jeden z důvodů využívat blokátor) je právě úspora zdrojů- cpu a RAM, což zde sedí jak butock na hrnec.  Příčinu to ale neřeší vůbec. 

Po jakém jiném browseru se poohlédnout? V tom duchu jak psal Jirsák, že chromium je optimalizováno pro nejvyšší rychlost a předpokládá hodně paměti a snaží se spoustu věcí dělat dopředu podobně jako procesory intel, kterým Spectra a meltdown zlomil vaz. Zde prohlížeči zlomil vaz nedostatek prostředků, na které je dělaný. (Přirovnání je tak trochu jako  hodinky a holinky)
Takže nějaký úsporný prohlížeč, který se snaží s pamětí šetřit, prostě aby priorita nebyla rychlost, ale úspornost.

O tomhle si mohu nechat zdát. nebo si z toho také mám dělat legraci, že po 10 tabech je zaplněný?

173

Software / Re:Chromium dává kouř paměťové kartě

« kdy: 15. 02. 2020, 12:08:08 »

Vždyť ani nejnovější raspberry pi nemá víc jak 4GB

1. mám High endurance microSD kartu, ale paradoxně má nižší IOPS, prý je to normální. zápis 25 MB/s, čtení neomezeně, nevíc microSD na RPI nedá víc jak 29MB/s(Nezodpovězeno)

2. Když zruším  cache na disku, do problémů se dostanu dříve (v čase) sice se ne zapisuje ale neustále se čte 16MB/s (450 requestů za sekundu). Když cache systemctl start dphys-swapfile zapnu, tak se to oddálí, než dojde k zaplnění swapu a to pak ten kouř je obousěrný - na kartu se navíc i neustále zapisuje a i když jde o max 2MB/s tak to způsobuje v iostatu write request delay v řádu 500-2000 ms,což je mnohem horší než když se jen čte,protože i při takto intenzivním čtení je read requst delay kolem 100-200 ms (což souvisí s vlastností NAND - jednoduché čtení, pro zápis nutno erase.
- Je to umocněno tím při zápisu je average write size kolem 5kB, zatímco u čtení 30kB

3. to mi nepřipadá jako dobrý nápad na 1GB stroji, kde je permanentně nedostatek volné RAM

4. Možná to tak dopadne, ale tím se ztrácí kompaktnost celého zařízení, snad jen takové ty piko flashky o velikosti USB vysílače k bezdrátovým myším, to ale není SSD.

5. Proč to takhle vůbec autoři raspbianu neudělali, vždyť jde o Tradiční řešení swapovské otázky na linuxu, že se používá swap oddíl a ne swap soubor...?

174

/dev/null / Re:jak zablokovat, ale částečně (podvrhování href v odkazu / wordpress)

« kdy: 15. 02. 2020, 11:55:23 »

.

175

/dev/null / jak zablokovat, ale částečně (podvrhování href v odkazu / wordpress)

« kdy: 04. 02. 2020, 13:46:37 »

Dobrý den, mám takové dilema v ublocku. Je o jistý skript, který zároveň dělá dobrou funkci ale i špatnou funkci. Je součásti wordpressu, tedy běží spoustě domén. Ale to je vlastně jedno, protože ho nebylo správné blokovat (přišel bych o dobré funkce)

doména.cz/wp-content/plugins/related-posts/related-posts.min.js -  načítá "příbuzné příspěvky" z adresy "doména.cz/názevčlánku?relatedposts=1" O tyto články stojím

Nimcéně ale skript dělá špatnou věc, že (dynamicky!) podvrhuje URL při kliknutí (tzn otevře se  "doména.cz/názevjiénohočlánku?relatedposts_hit=1&relatedposts_origin=23&relatedposts_position=2")

Kód: [Vybrat]

function s() {
        e.setVisualExcerptHeights(),
        t("#jp-relatedposts a.jp-relatedposts-post-a").click(function() {
            this.href = e.getTrackedUrl(this)
        })
    }

Zablokováním scriptu by se mi nenačetly vůbec "příbužné posty"

1.) Jak zablokotovat toto? v ublocku by šlo použít scriptlet +js(add-event-listener-defuser.js), který vykostí eventy na stránce, ale má to jeden problém, že pravidlo nelze použít bez specifikace domény (a jaksi nekonečný seznam všech domén je nemožná logická konstrukce).

2. Jak zamezit obecně všem stránkám podvrhovat href atribut. čili základní kámen hypertextu, že v odkazu A vidím v atributu href, na co kliknu.

3. Je nějaká věc která když už neumí věc č.2, že aspoň upozorní že podvržené URL se neshoduje s původním (definovaným staticky, nebo viděným v okamžiku najetí?) - podobně jako když omylem bych klikl na  google.com/sa?url=skutecnaadrea, tak ublock zařve že URL je  na seznam filtrů.

Jedno dementní ne-řešení existuje - před každým kliknutím na odkaz( si otevřít konzoli a) označit prvek (ctrl shift c), jelikož některé weby připíší URL již při kliknutí pravým tlačítkem nebo se ho snaží bonzovat. Ale řešení je to opravdu na draka, protože cílem href má být rychlá navigace podle toho co vidím jako HREF a ne hrabat se, co je původní href

176

Server / Různý obsah javascriptu podle způsobu načtení

« kdy: 30. 01. 2020, 23:10:57 »

Stránka načítá js skripty, např. bla.cz/skript.js. Umístění  normálně obsahuje běžný  javascript. Při pokusu otevřít daný skript jako URl manuálně, nebo opětovném načtení, nebo i při načtení z jiné adresy se místo obsahu scriptu vrátí jiný obsah?

Kód: [Vybrat]

uwm builtin protection

Jak to ? Samozřejmě při prvním načtení stránky s konzolí se  zaznamená pravý obsah.

177

Software / Re:Chromium dává kouř paměťové kartě

« kdy: 30. 01. 2020, 15:15:02 »

Zasa si nepozil google lebo by si vedel ze je to hned prvy odkaz ?
https://www.raspberrypi.org/forums/viewtopic.php?t=221967

Tam ale není odpovědi na mé dotazy

178

Software / Chromium dává kouř paměťové kartě

« kdy: 30. 01. 2020, 12:06:01 »

Všiml jsem si podivné věci, po nějaké době, co mám spuštěný chromium 75, rozhodne se že pořádně zatopí systému:
neustále čte z úložného zařízení (iostat hlásí 400 read operací za sekundu permanenentně ,odpovídající  5-12 MB/s, IO aktivní čas 99,2% až 100,02%) Nemusím říkat, že se systém extrémně zpomalí, například zavírání okna jiného programu trvá 5 sekunud a je vidět, jak obdélník okna mizí rychlostí 40 pixelů zas sekundu vertikálně)

V případě že zapnu swap, se začne pomalu ale jistě zaplňovat. Sice ustane permanentnní čtení, ale občas dělá i velké zápisy) Když se blíží k zaplněnení se systém zpomalí tak jako tak.

Ram je sice obazená (tak 550MB z 980) ale ne pln


Zajímalo by mě, proč  chromium takhle drtí disk a za druhé co je ten spouštěč tohodle škodění.

179

Hardware / Re:Prohozená polarita, notebook

« kdy: 29. 01. 2020, 13:31:34 »

v pohode zapoji notebook citi s neho smrad "delší dobu" a je viac menej spoko.

Měl by sis dát políček, keď neumíš počutat psaný text. Fabuluješ, co jsem nenapsal. Po zaprskání jsem zdroj odpojil a smrad se začal linout až později a na delší dobu. Nejenže jsem nebyl spoko už předtím než z něj byl cítit smrad ale už ani nebyl zapojený

180

Windows a jiné systémy / Re:e.foundation na Huawei Y6

« kdy: 29. 01. 2020, 12:44:56 »

Půjde to na Huawei Y6?