reklama

Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - beer

Stran: [1] 2 3 ... 48
1
Server / Re:Nextcloud: přihlášení Google účtem
« kdy: 07. 06. 2018, 08:40:08 »
Podporuje:https://github.com/zorn-v/nextcloud-social-login
Už jsem přišel na to, jak spárovat existující účet s účtem na sociální síti: po přihlášení heslemúplně dole na stránce v  nextcloudu na webu v url .../index.php/settings/user/additional zaškrtnout tu danou sociální síť a pokud jsem do ní přihlášen, tak se účet propojí.
Zatím jsem nevyřešil ten problém s klíčem. Vše mi funguje, šifrování v server side nextcloudu nevedu, takže se k souborům dostanu, ale rád bych to taky vyřešil.

2
Server / Nextcloud: přihlášení Google účtem
« kdy: 06. 06. 2018, 09:00:03 »
Zdravím, povolil jsem si přihlášení do nextcloudu google účtem. Místo, aby podle e-mailu rozpoznal nextcloud již existujícího uživatele, vytvoří nového se jménem google-nějaké číslo a zobrazuje hlášku:
Chybný soukromý klíč pro šifrovací aplikaci. Aktualizujte prosím heslo svého soukromého klíče v osobním nastavení, abyste znovu získali přístup ke svým zašifrovaným souborům.
Dají se tyto 2 nedostatky nějak vyřešit? I když uživateli vytvořím přímo heslo, a v nastavení Zapezpečení - základní šifrovací modul nastavím stejné heslo, tak to tu hlášku pořád píše.
Co bych tedy rád, aby se nevytvářeli noví uživatelé, když existuje stávající, a aby se vyřešila ta hláška šifrovacího modulu. U uživatelů, které vytvořím ručně to není, ale u těch není možné google přihlášení.

3
Vývoj / Re:Paralelní zpracování souboru
« kdy: 24. 02. 2018, 16:47:39 »
To je interní funkcionalita jpeg-recommpress, bohužel optipng to nemá.

Kód: [Vybrat]
optimages2.sh Obrázky/
File already processed by jpeg-recompress!
Metadata size is 15kb
smallfry at q=67 (40 - 95): 97.331100
smallfry at q=81 (68 - 95): 99.249321
smallfry at q=88 (82 - 95): 100.479576
smallfry at q=92 (89 - 95): 101.507240
smallfry at q=94 (93 - 95): 102.012131
smallfry at q=95 (95 - 95): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
Final optimized smallfry at q=95: 102.355392
New size is 58% of original (saved 1891 kb)
Metadata size is 15kb

4
Vývoj / Re:Paralelní zpracování souboru
« kdy: 24. 02. 2018, 13:41:46 »
Když zakomentuji png, tak to projde jen od největších jpg a vyčte si to z poznámky, že ten daný soubor to již zpracovávalo a dál ho nezpracovává.

Tak funguje to i na desktopu s Ubuntu, ale protože tam mám hodně velké soubory - obrázky, které mají poměrně dost megabajt, tak se zdá, jako kdyby to pořád pracovalo a nic se neděje. Ale pak už je to lepší. Nejhorší je to u skenů, u klasické fotky cca 5 MB trvá optimalizace pár minut.

Horší je, že narozdíl od severu na desktopu někdy stroj zamrzne, když se na něm dělá něco jiného. Přece jen je desktop starší a má jen dvě jádra. Kdybych odstranil -l 128 tak by to bylo mnohem mnohem rychlejší, ale ne s tak dobrými výsledky.

5
Vývoj / Re:Paralelní zpracování souboru
« kdy: 22. 02. 2018, 09:02:33 »
Tak funguje to napůl. Na debianu 9 bez problémů, na destkopu s ubuntu to taky dokáže vytížit na 100 % všechna jádra, ale bez jakéhokoliv výpisu a výsledek nikde. I když odstraním ty zpětná lomítka. V htopu vidím, že to něco dělá, ale žádný výstup a pořád nad stejnými soubory.

6
Vývoj / Re:Paralelní zpracování souboru | vyřešeno
« kdy: 22. 02. 2018, 02:42:32 »
Tak snad vyřešeno. S tím xargem mi to nešlo, parallel vypadá jednodušeji.


Aktuální verze skriptu:



Kód: [Vybrat]

#!/bin/bash
target="$1"


jpgfronta="$(mktemp)"
pngfronta="$(mktemp)"


find "$target" -type f -iname *.jp*g -exec du -a {} + | sort -n -r | cut -f 2 >"$jpgfronta"
find "$target" -type f -iname *.png -exec du -a {} + | sort -n -r | cut -f 2 >"$pngfronta"


cat "$jpgfronta" | parallel jpeg-recompress -q medium -l 128 -a -c -m smallfry \{} \{}
cat "$pngfronta" | parallel optipng -o7  \{} \{}


rm "$jpgfronta"
rm "$pngfronta"


exit


Funguje to pěkně rychle. Narozdíl od doplňků je to univerzální, nasadím to i na databázi fotek, protože opticky nepoznám rozdíl v kvalitě. A proč používám jpeg-recompress? Je to založené na mozjpeg od mozilly a asi nic efektivnějšího aktuálně není. Google má tuším něco podobného, ale to jsem nezkoušel.

7
Vývoj / Re:Paralelní zpracování souboru
« kdy: 21. 02. 2018, 17:29:54 »
žere, jsou povinné, zdrojový a cílový soubor. Když je to stejné, tak se optimalizuje soubor za běhu a zapíše se změna jen v případě, že soubor nebyl již optimalizovaný předtím, jpeg-recompress to řeší přidáním poznámky do metadat a při dalším spuštění nad stejným souborem soubor jednoduše přeskočí. Na rozdíl od optipng, to je hrozná brzda, která se snaží optimalizovat již optimalizované.

Vyzkouším, díky

8
Vývoj / Re:Paralelní zpracování souboru
« kdy: 21. 02. 2018, 17:07:04 »
A co třeba jen tevřít obrázky (případně přes search parametricky najít/filtrovat) v xnview a dát hromadnou konverzi?Mám ocit, že program nevyužívá jádra CPU. Případně Zoner Photo studio, zdarma

Používám Debian a Ubuntu. Na serveru nemám grafické prostředí.

ja jsem si takhle jednoduse kdysi v praveku na pocitacovem clusteru graboval cd a wav do mp3.
Jakože jednotlivé thready ripovaly jednotlivé skladby?
Nemůžu mluvit za adsfasdfasdfasd, ale řekl bych, že určitě takhle ne, laser bývá v mechanikách jen jeden. Spíše rippování do wavu v jednom vláknu a paralelní konverze všech wavů potom do komprimovaného formátu.

9
Vývoj / Re:Paralelní zpracování souboru
« kdy: 21. 02. 2018, 15:52:46 »
Nejjednodušší by bylo asi použití xargs, ale neumím to

zkusil jsem nahradit
Kód: [Vybrat]
while read line
do
printf "%s\n" "$line"
jpeg-recompress -q medium -l 128 -a -c -m smallfry "$(printf "%s\n" "$line")" "$(printf "%s\n" "$line")"
done < "$jpgfronta" &

tímto:
Kód: [Vybrat]
while read line
do
printf "%s\n" "$line"
"$(printf "%s\n" "$line")" "$(printf "%s\n" "$line")" | xargs --max-args=1 --max-procs=3 jpeg-recompress -q medium -l 128 -a -c -m smallfry
done < "$jpgfronta"

Ale mám tam nějakou chybu, obrázky to spouští jako spustitelné soubory a nepředává to cesty.

10
Vývoj / Re:Paralelní zpracování souboru
« kdy: 21. 02. 2018, 14:50:36 »
Vypadá to zajímavě, ale asi další kanón na vrabce. Ono se ti to řekne jednoduše, napíšeš si soubor build.ninja :-).

Rád bych šel cestou vrstvení standardních jednoúčelových nástrojů, aby to bylo čitelné pro mne i pro ostatní. Spočítání řádků přes wc, spočítání kolik odříznout kam přes dc, a pak případně použít head, tail či sed na vytvoření 3 různých front a & je hodit na pozadí.

Zkusím metodou pokus omyl :-).

11
Vývoj / Re:Paralelní zpracování souboru
« kdy: 21. 02. 2018, 13:46:38 »
Udělal bych to pomocí nástroje
Kód: [Vybrat]
make. Příkladů musí být na internetu tuny, umí i paralelní zpracování.
Předpokladem je, že optimalizované verze budou v jiném adresáři (nebo budou odlišené názvem).

Mrknu na to, není to ale kanón na vrabce? A makem lze soubor po řádcích rozdělit na stejně velké části?

12
Vývoj / Re:Paralelní zpracování souboru
« kdy: 21. 02. 2018, 13:39:45 »
Udělal bych to pomocí nástroje
Kód: [Vybrat]
make. Příkladů musí být na internetu tuny, umí i paralelní zpracování.
Předpokladem je, že optimalizované verze budou v jiném adresáři (nebo budou odlišené názvem).

Ten předpoklad na mém malém web serveru nelze splnit. Uživatel nahraje obrázek, wordpress z toho obrázku udělá x dalších obrázků - například:

uživatel nahraje
centruminvestic.cz/wp-content/uploads/2018/02/electrum-ltc.jpg

a wordpress udělá:














Navíc kdyby se optimalizovalo do jiné složky, nezobrazoval by se na webu optimalizovaný obrázek. Rovněž je potřeba na serveru šetřit místem.

ja bych se s tim vubec tak slozite nesral.
udelej si vypis (obrazkovych) souboru s vystupem do textoveho souboru: ls *.jpg > soubory,txt

soubor.txt rucne rozsekej na x kusu, podle toho kolik mas jader na tolik souboru: soubor1.txt, soubor2.txt.....souborX.txt

udelej si shel skript, ktery projizdi textovy soubor a z nazvu souboru (obrazku) v souborN.txt projedes fajly a zpracujes obrazky.

spustis skript x-krat:

./zpracovani soubor1.txt &> /dev/null &
./zpracovani soubor2.txt &> /dev/null &
./zpracovani souborX.txt &> /dev/null &

a nemusim vymyslet paralelni kraviny.
na prioritizaci kdyz zpracovavat male nebo velke obrazky se taky vyprdni. az ty skripty dojedou, tak dojedou.



Je to na webserveru, kde to script spouštím cronem. To ruční rozsekání je pro mne problém. Dejme tomu, že tam mám 4 jádra a chtěl bych tedy vždy spouštět 3x.

13
Vývoj / Paralelní zpracování souboru
« kdy: 21. 02. 2018, 12:32:59 »
Ahoj, vytvořil jsem si soubor pro optimalizaci obrázků na web serveru. Konfigurační příklady, které jsem na webu našel, byly velmi neefektivní, protože jedou jen v jednom vlákně a zkouší i soubory, které již byly optimalizovány.

Napadlo mne, že by bylo efektivnější obrázky nejprve seřadit dle velikosti a zařadit do fronty. To mi jakžtakž funguje, ale jen na jednom stroji s debianem 9, na ubuntu 17.10 mám chybové hlášky o tom, že to někde nemá ve složce přístup (zkoušel jsem do /tmp přesunout pár obrázků a zkoušel to tam), obrázky se ale v /tmp neoptimalizovali, přitom jsem použil stejný postup jako na web serveru mujscript.sh /tmp/.

Koukal jsem na nějaké příklady paralelního zpracování, ale moc se v tom neorientuji. Koukal jsem i na program Parallel, ale ne že bych z toho byl zrovna moudrý.

Zde je můj současný skript:

Kód: [Vybrat]
#!/bin/bash
target="$1"

jpgfronta="$(mktemp)"
pngfronta="$(mktemp)"

find "${target}/" -type f -iname *.jp*g -exec du -a {} + | sort -n -r | cut -f 2 >"$jpgfronta"
find "${target}/" -type f -iname *.png -exec du -a {} + | sort -n -r | cut -f 2 >"$pngfronta"

while read line
do
printf "%s\n" "$line"
jpeg-recompress -q medium -l 128 -a -c -m smallfry "$(printf "%s\n" "$line")" "$(printf "%s\n" "$line")"
done < "$jpgfronta" &

while read line
do
printf "%s\n" "$line"
optipng -quiet -o7 "$(printf "%s\n" "$line")"
done < "$pngfronta" &

rm "$jpgfronta"
rm "$pngfronta"

exit

Myslím, že by bylo efektivnější, kdyby se zpracovávali najednou soubory dle počtu jader, jedno jádro by se nechalo nevyužité. Ve frontě jsou názvy souborů pro zpracování, v jednom sloupci. Možná by bylo jednodušší soubor rozdělit do sloupců dle počtu jader -1 a zpracovávat po řádku. Na to jsem nějaký skript na webu viděl, ale nevím jak na to. Nebo prostřednictvím toho paralelu nebo xargs.

Poradí někdo, jak docílit paralelního zpracování s větší prioritou zpracování pro velké soubory?

14
Server / Re:Aktualizace Nextcloud z verze 12 na 13 selhává
« kdy: 08. 02. 2018, 15:44:17 »
Viz https://github.com/Wonderfall/dockerfiles/issues/178, i když to není úplně relevantní, protože se to týká nextcloudu v dockeru, tedy jiné konfigurace.

15
Server / Re:Aktualizace Nextcloud z verze 12 na 13 selhává
« kdy: 08. 02. 2018, 15:41:36 »
Ty vaše nalezené chyby neřeší ale nextcloud, ale mariadb jako takové. Ale jedná se zřejmě o chybu v nextcloud, který nedokáže sám vyprázdnit cache z databáze.

Stran: [1] 2 3 ... 48

reklama