1
Odkladiště / Re:Jaký je váš nejoblíbenější grepový příkaz?
« kdy: 27. 05. 2018, 12:21:56 »
Typicky grep -rnI
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.
2
Desktop / Re:Jak můžu smazat všechno?
« kdy: 10. 05. 2018, 17:19:47 »Jinak existuje příkaz shred, kterému se dá zadat co přesně má udělat a kolikrát, a pak se nechá jenom několik dní pracovat.
Ano, shred je nejlepší volba. Třeba:
Kód: [Vybrat]
sudo shred -n 5 -z /dev/sdxPokud člověk nemá k dispozici shred, tak mimikovat jeho chování přes dd.
Tip: když se dd pošle SIGUSR1, vypíše na stderr kolik ním zatím proteklo dat
3
Software / Re:Rsync s --append-verify
« kdy: 20. 01. 2018, 17:38:39 »
Vzhledem k tomu, jak se to chovalo s tím --append-verify, tak pro dosynchronizaci souborů, ktery se měnily ale nezvětšovaly, stačilo ten parametr zahodit. Každopádně přeběhnout to s -c je dobrej nápad, díky za něj, ale nic novyho to podle očekávání nenašlo.
Tímhle sem si dělal jenom nějaky konkrétní menší remote zálohy rozpracované práce (která se typicky zvětšovala, navíc to opravdu důležity mám v gitu), takže bych reálně (naštěstí) přišel max o výsledky a grafy, ktery si můžu znova vygenerovat, takže pár hodin chroupání dat a bylo by to.
Na zálohování na externí disk nebo NAS sem ten append ale nepoužíval, tam smysl nemá, takže kompletní (i když míň časty) zálohy sem měl.
Je ale pravda, že to bylo solidní rozčarování, jakou blbost sem delší dobu dělal.
Tímhle sem si dělal jenom nějaky konkrétní menší remote zálohy rozpracované práce (která se typicky zvětšovala, navíc to opravdu důležity mám v gitu), takže bych reálně (naštěstí) přišel max o výsledky a grafy, ktery si můžu znova vygenerovat, takže pár hodin chroupání dat a bylo by to.
Na zálohování na externí disk nebo NAS sem ten append ale nepoužíval, tam smysl nemá, takže kompletní (i když míň časty) zálohy sem měl.
Je ale pravda, že to bylo solidní rozčarování, jakou blbost sem delší dobu dělal.
4
Software / Re:Rsync s --append-verify
« kdy: 19. 01. 2018, 19:13:22 »
Jo, to jsem pochopil. Akorát sem používal variantu s verify, takže pokud se soubory jenom zvětšily nebo vznikly nové (což se dělo vlastně prakticky vždy), vše fungovalo jakoby správně, rsync akorát při kontrole existujících zvětšených křičel pokud se změnil obsah, a nahrál ho tam znovu (akorát proti tomu, co říkáte, to zjistil ještě než cokoli novyho uploadnul). Kdybych nepoužíval verify, tak si toho všimnu hned, protože by zálohy neprobíhaly korektně. To, že se zálohovalo korektně a seděly všechny kontrolní součty, byla vlastně náhoda způsobená specifikem těch dat, co se zálohovaly.
Až teď při experimentování jsem ale došel na skutečny chování, a že to nedělá to, co potřebuju (což přesně dělá --partial)
Každopádně ponaučení je, že i když si člověk při pár prvních iteracích ověří, že zálohování probíhá korektně, neznamená to, že všecko probíhá správně a do budoucna nebude problém.
Disclaimer: šlo o moje osobní zálohy, ne o nějakou produkční záležitost (nic takovyho ani pod palcem nemám).
Až teď při experimentování jsem ale došel na skutečny chování, a že to nedělá to, co potřebuju (což přesně dělá --partial)
Každopádně ponaučení je, že i když si člověk při pár prvních iteracích ověří, že zálohování probíhá korektně, neznamená to, že všecko probíhá správně a do budoucna nebude problém.
Disclaimer: šlo o moje osobní zálohy, ne o nějakou produkční záležitost (nic takovyho ani pod palcem nemám).
5
Software / Re:Rsync s --append-verify
« kdy: 19. 01. 2018, 16:33:13 »Ten parametr nemá nic společného s navázáním po přerušení spojení a má dělat přesně to, co popisujete. K navazování přerušených spojení je možné použít --partial, který ponechá soubor na místě (nemaže jej), i když se spojení přeruší. Parametr --append slouží k tomu, když víte, že se soubor nikdy nemění, jenom se přidává na konec – takže tím rsyncu řeknete, ať se nestará o to, co už v souboru je, ale jenom přidá to, co přibylo na druhé straně. Dalo by se to použít třeba pro přenos logů.
Super, díky. Kdysi když sem četl man rsync a hledal navazování, narazil sem první na append a k partial se nedostal
6
Software / Re:Rsync s --append-verify
« kdy: 19. 01. 2018, 15:28:01 »
Jinak samozřejmě v manpage je to chování s navazováním popsany, ale není tam zmínka o tom, že se začnou ignorovat novější timestampy na zdroji.
To chování bych chápal, pokud by timestamp byl na zdroji starší nebo stejný jako v cíli. Ale ne, pokud je novější...
To chování bych chápal, pokud by timestamp byl na zdroji starší nebo stejný jako v cíli. Ale ne, pokud je novější...
Kód: [Vybrat]
--append
This causes rsync to update a file by appending data onto the
end of the file, which presumes that the data that already
exists on the receiving side is identical with the start of the
file on the sending side. If a file needs to be transferred and
its size on the receiver is the same or longer than the size on
the sender, the file is skipped. This does not interfere with
the updating of a file’s non-content attributes (e.g. permis-
sions, ownership, etc.) when the file does not need to be trans-
ferred, nor does it affect the updating of any non-regular
files. Implies --inplace, but does not conflict with --sparse
(since it is always extending a file’s length).
--append-verify
This works just like the --append option, but the existing data
on the receiving side is included in the full-file checksum ver-
ification step, which will cause a file to be resent if the
final verification step fails (rsync uses a normal, non-append-
ing --inplace transfer for the resend).
Note: prior to rsync 3.0.0, the --append option worked like
--append-verify, so if you are interacting with an older rsync
(or the transfer is using a protocol prior to 30), specifying
either append option will initiate an --append-verify transfer.
7
Software / Rsync s --append-verify
« kdy: 19. 01. 2018, 15:11:40 »
Zvykl jsem si u rsync v remote zálohovacích skriptech používat parametr --append-verify, jednak pro navázání po případnym přerušení spojení, ale taky aby v takových případech nezůstaly v destinaci ležet skryty nedokončeny fragmenty.
Jenže teď sem si všiml, že se v určité situaci nechová, jak bych čekal.
Pokud se nějaký soubor nepřenesl úplně, v pořádku, naváže se.
Pokud se nějaký soubor změnil a zvětšil se, celkem v pořádku, rsync provede kontrolu obsahu, všimně si změny a přenese ho znova (akorát při tom huláká varování, i když to měl čekat, když má zdroj novější timestamp).
ALE: Pokud se soubor změní, s tím že se jeho velikost nezmění nebo se zmenší, tak ho rsync nepřenese
(přestože má novější timestamp)
Když odstraním parametr --append-verify, tak vše probíhá normálně a změna se nasynchronizuje.
Nejradši bych, aby rsync zároveň navazoval (s kontrolou dosavadního obsahu), ale taky zároveň nerezignoval na kontrolu timestampu, což teď zjevně dělá. Zatím asi jako workaround ho po dokončení s --append-verify zavolám znova bez něj...
Používám rsync 3.1.0
Vypadá to teda, že ten parametr se má používat jenom po přerušenym spojení, a ne běžně, protože pak ignoruje timestampy. Ale i tak je to problém, pokud při přerušenym přenosu nedošla řada na nějaky další soubory a cíl nebyl prázdnej, tak už je s tím appendem bude posuzovat jinak (IMO špatně).
Je to očekávané chování, nebo bug? (Kdyžtak nareportuju). Osobně bych předpokládal, že i s --append-verify, pokud si všimne že má zdroj novější timestamp, tak normálně změněný soubor přenese. Obyčejnej --append se chová podobně, akorát samozřejmě selže i v případě zvětšení - na novější timestamp na zdroji ale kašle úplně stejně.
Demonstrace:
Jenže teď sem si všiml, že se v určité situaci nechová, jak bych čekal.
Pokud se nějaký soubor nepřenesl úplně, v pořádku, naváže se.
Pokud se nějaký soubor změnil a zvětšil se, celkem v pořádku, rsync provede kontrolu obsahu, všimně si změny a přenese ho znova (akorát při tom huláká varování, i když to měl čekat, když má zdroj novější timestamp).
ALE: Pokud se soubor změní, s tím že se jeho velikost nezmění nebo se zmenší, tak ho rsync nepřenese
(přestože má novější timestamp)Když odstraním parametr --append-verify, tak vše probíhá normálně a změna se nasynchronizuje.
Nejradši bych, aby rsync zároveň navazoval (s kontrolou dosavadního obsahu), ale taky zároveň nerezignoval na kontrolu timestampu, což teď zjevně dělá. Zatím asi jako workaround ho po dokončení s --append-verify zavolám znova bez něj...
Používám rsync 3.1.0
Vypadá to teda, že ten parametr se má používat jenom po přerušenym spojení, a ne běžně, protože pak ignoruje timestampy. Ale i tak je to problém, pokud při přerušenym přenosu nedošla řada na nějaky další soubory a cíl nebyl prázdnej, tak už je s tím appendem bude posuzovat jinak (IMO špatně).
Je to očekávané chování, nebo bug? (Kdyžtak nareportuju). Osobně bych předpokládal, že i s --append-verify, pokud si všimne že má zdroj novější timestamp, tak normálně změněný soubor přenese. Obyčejnej --append se chová podobně, akorát samozřejmě selže i v případě zvětšení - na novější timestamp na zdroji ale kašle úplně stejně.
Demonstrace:
Kód: [Vybrat]
Tom@HP-ProBook-TK~/temp/rsync_append> mkdir src && mkdir dest && echo aaa > src/a.txt
Tom@HP-ProBook-TK~/temp/rsync_append> rsync -a -v -h --append-verify src/ dest/
sending incremental file list
a.txt
sent 122 bytes received 35 bytes 314.00 bytes/sec
total size is 4 speedup is 0.03
Tom@HP-ProBook-TK~/temp/rsync_append> cat src/a.txt dest/a.txt
aaa
aaa
Tom@HP-ProBook-TK~/temp/rsync_append> echo aba > src/a.txt
Tom@HP-ProBook-TK~/temp/rsync_append> rsync -a -v -h --append-verify src/ dest/
sending incremental file list
sent 74 bytes received 12 bytes 172.00 bytes/sec
total size is 4 speedup is 0.05
Tom@HP-ProBook-TK~/temp/rsync_append> cat src/a.txt dest/a.txt
aba
aaa
Tom@HP-ProBook-TK~/temp/rsync_append> rsync -a -v -h src/ dest/
sending incremental file list
a.txt
sent 125 bytes received 35 bytes 320.00 bytes/sec
total size is 4 speedup is 0.03
Tom@HP-ProBook-TK~/temp/rsync_append> cat src/a.txt dest/a.txt
aba
aba
Tom@HP-ProBook-TK~/temp/rsync_append> echo abaa > src/a.txt
Tom@HP-ProBook-TK~/temp/rsync_append> rsync -a -v -h --append-verify src/ dest/
sending incremental file list
a.txt
WARNING: a.txt failed verification -- update retained (will try again).
a.txt
sent 177 bytes received 156 bytes 666.00 bytes/sec
total size is 5 speedup is 0.02
Tom@HP-ProBook-TK~/temp/rsync_append> cat src/a.txt dest/a.txt
abaa
abaa
8
Software / Re:OCR z stacionárního videa
« kdy: 06. 05. 2017, 14:51:08 »Rozpoznání segmentového displeje by mohlo být triviální, ne? Stačí poznat které segmenty svítí a porovnat se vzorem. Akorát by se musela nakalibrovat poloha displeje a světelné podmínky - asi nejsložitější část, aby to bylo prakticky použitelné. Takže OCR snad ani není potřeba (a nevím, zda by se vyplatilo ho použít).Presne to me taky napadlo, jedina podminka je, aby byl displej ve fixni pozici.
Dalo by se to i bez vetsich problemu udelat samokalibracni - udelat si pri kazdem rozpoznavani histogram svetelnosti definovane oblasti obrazu, kde je displej, v nem rozpoznat 2 peaky (svetly a tmavy). Mezi nimi pak nastavit threshold a s nim porovnavat svetelnost vybranych ploch (staci treba mensi obdelnikova ploska), kde jsou segmenty.
To cele bud nad cernobilym obrazem, nebo nad barevnym kanalem, ktery ma pro ten displej nejlepsi kontrast. A pokud je displej vypnuty, pozna se to tak, ze ten peak v tom histogramu bude jen jeden.
9
Server / Re:Deduplikace záloh
« kdy: 29. 03. 2017, 17:28:26 »Neexistuje nějaký souborový systém podobný taru, který je možné bzipovat?Nezávisle na FS...
Kód: [Vybrat]
sudo dd if=/dev/sda1 | bzip2 > ~/sda1.bz2
10
Server / Re:Sdílení dat mezi dvěma RPi
« kdy: 18. 02. 2017, 15:00:51 »
Nejprimitivnejsi a dostatecny by me prislo mit ssh klice + scp s rozumnym timeoutem a kontrolou navratove hodnoty.
To scp se muze logovat na spesl uzivatele s adekvatnima pravama (cteni jen toho souboru a zapis nikde), pokud se to cloveku chce resit.
To scp se muze logovat na spesl uzivatele s adekvatnima pravama (cteni jen toho souboru a zapis nikde), pokud se to cloveku chce resit.
11
Hardware / Re:Poraďte kvalitní zvukovku pro Linux
« kdy: 29. 10. 2016, 13:20:03 »
Hm. Zas nekdo vykopal roky stary vlakno a postnul do nej tak trochu souvisejici ale jinej dotaz. A ted vsichni odpovidaj na ten puvodni...
Abych nebyl uplne OT: mam Fiio X3 (1. gen.) a funguje paradne, navic je to kompaktni a clovek to uzije i jako prenosnej prehravac. Pucenej sem pak mel Audinst HUD-mx1 a taky v pohode, ale to sme porad v USB vodach.
To X3 me akorat s Linuxem nefungovalo, kdyz sem mu dal firmware 3.4, a to na ruznych (i cerstvych) distrech s podobnymi projevy (vymrzani nastaveni zvukovych zarizeni az celyho DE). Ale s 3.3 nebo niz v pohode.
Abych nebyl uplne OT: mam Fiio X3 (1. gen.) a funguje paradne, navic je to kompaktni a clovek to uzije i jako prenosnej prehravac. Pucenej sem pak mel Audinst HUD-mx1 a taky v pohode, ale to sme porad v USB vodach.
To X3 me akorat s Linuxem nefungovalo, kdyz sem mu dal firmware 3.4, a to na ruznych (i cerstvych) distrech s podobnymi projevy (vymrzani nastaveni zvukovych zarizeni az celyho DE). Ale s 3.3 nebo niz v pohode.
12
Odkladiště / Re:Název ajťácké punkové kapely
« kdy: 29. 07. 2016, 23:16:10 »
Fork B0mb
GOTO HELL (nebo jinam vhodne smerovany goto, hell je spis pro metalovou kapelu)
Punk++
sudo undelete punk
GOTO HELL (nebo jinam vhodne smerovany goto, hell je spis pro metalovou kapelu)
Punk++
sudo undelete punk
13
Software / Re:Návrat plánovače BFQ
« kdy: 15. 02. 2016, 01:14:42 »Na desktop s HDD se doporučuje BFQ, s čímž spíš souhlasím. Zrovna mám za sebou pokus o ruční opatchování gentoo-sources a z nějakýho důvodu to na BFQ patchi padá, takže jdu prozatím na deadline. Z toho vyplývá, že začlenění do mainline bych fakt ocenil.K cemu se doporucuje sem si primo nezjistoval, ale podle featur a benchmarku me to prave pripadalo idealni pro desktop s rotacnim diskem, u SSD bych byl na vazkach, ale snad i to by slo dobre.
Cemu ale moc nerozumim je pristup vyvojaru jadra, kdy doporucili pripravit patche, kterymi by se na chovani BFQ upravil stavajici CFQ (coz prave autor BFQ pripravil). Ja bych to ale radeji videl jako novou volbu, protoze CFQ je provereny a podobnost az tak vyrazna neni, hlavne je trochu jednodussi nez BFQ (i kdyz porad patri k tem komplexnejsim). Dokazu si predstavit, ze nahrazeni CFQ by vyvolalo rozruch.
14
Software / Návrat plánovače BFQ
« kdy: 12. 02. 2016, 20:38:39 »
U konkurence sem zahlidl clanek: http://www.abclinuxu.cz/clanky/jaderne-noviny-4.-2.-2016-navrat-planovace-bfq
Jak to mate vy s I/O schedulery?
Osobne na desktopovym systemu (notebook s rotacnim diskem) uz delsi dobu pouzivam deadline, protoze CFQ silne zaostava napr. pri prehravani hudby, pokud na pozadi bezi intenzivni cteni (rsync zaloha na externi disk, ktery je rychlejsi nez interni v notebooku). Prehravac (Clementine) obcas vyhladovi a prestane hrat, i kdyz mam buffer na 8s. S deadlinem sem mnohem spokojenejsi, i kdyz jeho celkovy vykon pri narazu na deadline cteni je znatelne nizsi. Odstrani ale ty extremni problemy. S nastavovanim I/O priorit se me nechtelo babrat.
Rad proto vidim, ze ma urcitou sanci na zarazeni do jadra novy planovac, ktery podle dosavadnich benchmarku vypada hodne slibne (https://lwn.net/Articles/674300/ tabulka ke konci). At uz CFQ (ze ktereho puvodne vychazi) nahradi, nebo pribude jako nova moznost.
Jak to mate vy s I/O schedulery?
Osobne na desktopovym systemu (notebook s rotacnim diskem) uz delsi dobu pouzivam deadline, protoze CFQ silne zaostava napr. pri prehravani hudby, pokud na pozadi bezi intenzivni cteni (rsync zaloha na externi disk, ktery je rychlejsi nez interni v notebooku). Prehravac (Clementine) obcas vyhladovi a prestane hrat, i kdyz mam buffer na 8s. S deadlinem sem mnohem spokojenejsi, i kdyz jeho celkovy vykon pri narazu na deadline cteni je znatelne nizsi. Odstrani ale ty extremni problemy. S nastavovanim I/O priorit se me nechtelo babrat.
Rad proto vidim, ze ma urcitou sanci na zarazeni do jadra novy planovac, ktery podle dosavadnich benchmarku vypada hodne slibne (https://lwn.net/Articles/674300/ tabulka ke konci). At uz CFQ (ze ktereho puvodne vychazi) nahradi, nebo pribude jako nova moznost.
15
O serveru Root.cz / Re:Nový Root již dnes?
« kdy: 27. 01. 2016, 23:20:05 »http://s10.postimg.org/bqxzpnbgp/Clipboard01.png
Win 7, FF 24.8.1
hochu to máš verzi z doby kdy můj fotr ještě točil bony
venku už je nejmíň verze 30
Ja mam FF 43.
Chrome uz je 47.
Dohnat a predehnat!
