1
Bazar / Re:Prodám MikroTik RB4011
« Poslední příspěvek od amay5267 kdy Dnes v 16:38:16 »Mám záujem ak doručujete aj na Slovensko.
Poslední příspěvky
3
Software / Re:Utilita du se chová divně nad NFS/BTRFS
« Poslední příspěvek od RDa kdy Dnes v 15:11:24 »Kralovstvi a pul princezny za patch, kde NFS bude prenaset device-minor pro subvolumes na druhej breh! 
4
Bazar / Prodám MikroTik RB4011
« Poslední příspěvek od Radek6h5 kdy Dnes v 15:08:18 »Prodám router MikroTik RB4011 ve výborném stavu, používán pouze cca 14 dní. Router je plně funkční, kompletní balení.
• Výkonný router vhodný pro náročnější domácí i firemní sítě
• 10× Gigabit LAN port
• SFP+ port (10Gbps)
• 4jádrový procesor, 1 GB RAM
• Podpora VLAN, VPN, firewallu a dalších pokročilých funkcí
Důvod prodeje: přechod na FortiGate.
• Výkonný router vhodný pro náročnější domácí i firemní sítě
• 10× Gigabit LAN port
• SFP+ port (10Gbps)
• 4jádrový procesor, 1 GB RAM
• Podpora VLAN, VPN, firewallu a dalších pokročilých funkcí
Důvod prodeje: přechod na FortiGate.
5
Software / Re:Utilita du se chová divně nad NFS/BTRFS
« Poslední příspěvek od Michal Šmucr kdy Dnes v 14:10:45 »Aha, už sis odpověděl sám mezitím
6
Software / Re:Utilita du se chová divně nad NFS/BTRFS
« Poslední příspěvek od Michal Šmucr kdy Dnes v 14:09:37 »Ahoj. To je podle mě kvůli tomu, že ty btrfs subvolumy v NFS mountu mají vždycky stejný inode a společný device.
Porovnej si to přes výstup ze stat lokálně a přes NFS.
Takže to du nerozliší a ty položky, co mají stejný dev i inode, při procházení vyhazuje. Neznám teď konkrétní mechanismus, musel bych to někde hledat ve zdrojáku coreutils.. ale typicky se to dělá kvůli tomu, abys nezpracovával/nepočítal vícekrát položky, co jsou hardlinkované.
Myslím, že i proto je tam obecné doporučení ty subvolumy sdílet přes NFS zvlášť a přidat jim unikátní ID.
https://btrfs.readthedocs.io/en/latest/Interoperability.html#nfs
Ještě jinak ty du výstupy přes NFS bude chtít brát trochu s rezervou, pokud jsou v té struktuře třeba reflinky (soubory sdílí extenty), což se podle mě projeví tak, že to spočítá víckrát.
Porovnej si to přes výstup ze stat lokálně a přes NFS.
Takže to du nerozliší a ty položky, co mají stejný dev i inode, při procházení vyhazuje. Neznám teď konkrétní mechanismus, musel bych to někde hledat ve zdrojáku coreutils.. ale typicky se to dělá kvůli tomu, abys nezpracovával/nepočítal vícekrát položky, co jsou hardlinkované.
Myslím, že i proto je tam obecné doporučení ty subvolumy sdílet přes NFS zvlášť a přidat jim unikátní ID.
https://btrfs.readthedocs.io/en/latest/Interoperability.html#nfs
Ještě jinak ty du výstupy přes NFS bude chtít brát trochu s rezervou, pokud jsou v té struktuře třeba reflinky (soubory sdílí extenty), což se podle mě projeví tak, že to spočítá víckrát.
7
Software / Re:Utilita du se chová divně nad NFS/BTRFS
« Poslední příspěvek od RDa kdy Dnes v 14:04:56 »Takže problém je, že NFS maskuje informaci o subvolumes v kombinaci že btrfs má neunikátní inode numbers mezi subvolumes.
Lokálně btrfs idenfikuje subvolume skrze jiný device minor, viz:
Server:
Klient:
A pak příkaz du obsahuje unique redukci skrze hash a netuší, že tyhle dvě věci jsou rozdílné (na lokálu to pozná, potože tam vstupuje i device do hashu).
Taky neexistuje žádný přepínač v du, který by hashování vyplo nebo započetlo všechny výskyty souborů. Podle zdrojáku se hash zapíná, když je uvedeno více než dva argumenty, takže pro můj příklad je funkční řešení tohle (za podmínky, že už tyto argumenty nebudou obsahovat další subvolumes):
REF:
The Btrfs inode-number epic (part 1: the problem)
https://lwn.net/Articles/866582/
+
The Btrfs inode-number epic (part 2: solutions)
https://lwn.net/Articles/866709/
z těchto návrhů ale není v jádru akceptované nic jestli dobře vidím.
Současný stav věci je, že si mám jako ručně v /etc/exports vypsat všechny subvolumes (LOL fakt):
https://btrfs.readthedocs.io/en/latest/Interoperability.html#nfs
ale to dělat nebudu.. protože pak při použití df bude ta stovka subvolumes prasit výstup identickým výpisem o užitém/volném místu. Nevím zda má NFS auto-umount těch sub-mountů po nějaké době nečinnosti.
Lokálně btrfs idenfikuje subvolume skrze jiný device minor, viz:
Server:
Kód: [Vybrat]
# stat xxx yyy | grep -E 'Device|Inode'
Device: 0,198 Inode: 256 Links: 1
Device: 0,201 Inode: 256 Links: 1
Klient:
Kód: [Vybrat]
# stat xxx yyy | grep -E 'Device|Inode'
Device: 0,46 Inode: 256 Links: 1
Device: 0,46 Inode: 256 Links: 1
A pak příkaz du obsahuje unique redukci skrze hash a netuší, že tyhle dvě věci jsou rozdílné (na lokálu to pozná, potože tam vstupuje i device do hashu).
Taky neexistuje žádný přepínač v du, který by hashování vyplo nebo započetlo všechny výskyty souborů. Podle zdrojáku se hash zapíná, když je uvedeno více než dva argumenty, takže pro můj příklad je funkční řešení tohle (za podmínky, že už tyto argumenty nebudou obsahovat další subvolumes):
Kód: [Vybrat]
ls | xargs -n 1 sudo du --si -shREF:
The Btrfs inode-number epic (part 1: the problem)
https://lwn.net/Articles/866582/
+
The Btrfs inode-number epic (part 2: solutions)
https://lwn.net/Articles/866709/
z těchto návrhů ale není v jádru akceptované nic jestli dobře vidím.
Současný stav věci je, že si mám jako ručně v /etc/exports vypsat všechny subvolumes (LOL fakt):
https://btrfs.readthedocs.io/en/latest/Interoperability.html#nfs
ale to dělat nebudu.. protože pak při použití df bude ta stovka subvolumes prasit výstup identickým výpisem o užitém/volném místu. Nevím zda má NFS auto-umount těch sub-mountů po nějaké době nečinnosti.
8
Software / Re:Spojení animovaných gifů do jednoho obrázku
« Poslední příspěvek od Honza1Ubuntu kdy Dnes v 13:18:09 »Chápu to tak, že tazatel má více souborů a některé nebo všechy soubory jsou již animované gify, každý s několika snímky ?
Já bých to udělal tak, že nejprve bych onen animovaný GIF o více snímcích rozložil na jednotlivé snímky, každý snímek do jednotlivého GIF souboru. Názvy by už měl program generovat automaticky, tak aby výsledné soubory ve složce byly abecedně řazené (po rozložení více animovaných gifů v jedné složce bude abecední řazení stejné jako původně). To umí v Linuxu tuším XN View, ale nejsem si jistý. ImageMagick by to také měl zvládnout. Vím, že to umělo ACDsee, což je ale komerční software.
Druhou věcí je vytvoření animace z jednotlivých snímků. GIF animaci umí vytvořit tuším zase ten XN View. Nebo Image Magick (ale tohle přesně jsem celé roky nedělal). Když by byla GIF animace dlouhá (hodně snímků), tak je to sice bezstrátová komprese (na grafy, mapy, shémata vhodná, na video-foto nikoliv). Ale problém u animovaný GIF je ten, že při otevření se všechny snímky načtou do paměti jako nekomprimované BMP (zábere to paměť jako Výška X Šířka X Barevná hloubka X Počet Snímků). To už dneska není takový problém.
U rozsáhných animací (výstup modelu, přechod bouřky a pod.) jsem vytvářel animaci pomocí FFMPEG. Je to sice ztrátová komprese, ale u animací s hodně snímky a vysokým rozlišení je to nezbytnost. Kompresní kodek používám MPG, úroveň komprese 5, přípona souboru mp4. Zkoušel jsem i kodeky H264 a H265. Tam ten poměr kvalita-velikost souboru nebyl u map, animací, shémat o tolik lepší, než u MPG. U filmů to je jiná, tam se to vyplatí. H264 a H265 je výpočetně pro tvorbu souboru samozřejmě náročnější.
Takhle jsem vytvářel animaci z výstupu modelu (zvoleno h264 kvalita maximální, komprese malá, výsledný soubor velký):
Výsledné MKV video je velké, zkonvertoval jsem např. pomocí Handbrake na MPG4 (MP4), úroveň komprese-kvalita jsem nastavil 5, což jsou dobré výsledky na obě strany.
V ffmpeg jsem experimentoval i s h265 a h264. Hlavně u h265 výpočetní náročnost vysoká.
Převod videa na h264, CRF_NUMBER je úroveň komprese (CRF 15 malá komprese, dobrá kvalita, CRF 23 poměrně dobrá komprese, kvalita také docela jde)
Já bých to udělal tak, že nejprve bych onen animovaný GIF o více snímcích rozložil na jednotlivé snímky, každý snímek do jednotlivého GIF souboru. Názvy by už měl program generovat automaticky, tak aby výsledné soubory ve složce byly abecedně řazené (po rozložení více animovaných gifů v jedné složce bude abecední řazení stejné jako původně). To umí v Linuxu tuším XN View, ale nejsem si jistý. ImageMagick by to také měl zvládnout. Vím, že to umělo ACDsee, což je ale komerční software.
Druhou věcí je vytvoření animace z jednotlivých snímků. GIF animaci umí vytvořit tuším zase ten XN View. Nebo Image Magick (ale tohle přesně jsem celé roky nedělal). Když by byla GIF animace dlouhá (hodně snímků), tak je to sice bezstrátová komprese (na grafy, mapy, shémata vhodná, na video-foto nikoliv). Ale problém u animovaný GIF je ten, že při otevření se všechny snímky načtou do paměti jako nekomprimované BMP (zábere to paměť jako Výška X Šířka X Barevná hloubka X Počet Snímků). To už dneska není takový problém.
U rozsáhných animací (výstup modelu, přechod bouřky a pod.) jsem vytvářel animaci pomocí FFMPEG. Je to sice ztrátová komprese, ale u animací s hodně snímky a vysokým rozlišení je to nezbytnost. Kompresní kodek používám MPG, úroveň komprese 5, přípona souboru mp4. Zkoušel jsem i kodeky H264 a H265. Tam ten poměr kvalita-velikost souboru nebyl u map, animací, shémat o tolik lepší, než u MPG. U filmů to je jiná, tam se to vyplatí. H264 a H265 je výpočetně pro tvorbu souboru samozřejmě náročnější.
Takhle jsem vytvářel animaci z výstupu modelu (zvoleno h264 kvalita maximální, komprese malá, výsledný soubor velký):
Kód: [Vybrat]
ffmpeg -framerate 30 -pattern_type glob -i '*.png' -c:v h264 -s 2000x1000 -x264-params crf=0 "Video.mkv"
Výsledné MKV video je velké, zkonvertoval jsem např. pomocí Handbrake na MPG4 (MP4), úroveň komprese-kvalita jsem nastavil 5, což jsou dobré výsledky na obě strany.
V ffmpeg jsem experimentoval i s h265 a h264. Hlavně u h265 výpočetní náročnost vysoká.
Převod videa na h264, CRF_NUMBER je úroveň komprese (CRF 15 malá komprese, dobrá kvalita, CRF 23 poměrně dobrá komprese, kvalita také docela jde)
Kód: [Vybrat]
nice -n 19 ffmpeg -i Puvodni_Video.mkv -c:v libx264 -preset veryslow -x264-params crf=${CRF_NUMBER} Nove_Video.mp4
9
Bazar / Prodám/daruji Dell Latitude C800
« Poslední příspěvek od hadgs kdy Dnes v 13:03:34 »Zdravím
Našel jsem při úklidu doma starý notebook Dell Latitude C800. Měl by o něj někdo zajem do sbírek?
Cpu PentiumIII 850 MHz, 256 MB Ram, 40 GB disk, ATI Rage 128, 14" 1400x1050 displej.
Známky používání, tu a tam odlomený kousek tenkého plastu, panty slabší, trackpoint utržený. Ještě je k tomu krabička s náhradními součástkami.
Bude-li zájem, tak to rozchodím a vyčistím, jinak se mi s tím nechce babrat a půjde to do šrotu.
Kdysi celkem úspěšně na tom běhaly WinXP, potom několik let Ubuntu od 8.04 po snad 9.10
Našel jsem při úklidu doma starý notebook Dell Latitude C800. Měl by o něj někdo zajem do sbírek?
Cpu PentiumIII 850 MHz, 256 MB Ram, 40 GB disk, ATI Rage 128, 14" 1400x1050 displej.
Známky používání, tu a tam odlomený kousek tenkého plastu, panty slabší, trackpoint utržený. Ještě je k tomu krabička s náhradními součástkami.
Bude-li zájem, tak to rozchodím a vyčistím, jinak se mi s tím nechce babrat a půjde to do šrotu.
Kdysi celkem úspěšně na tom běhaly WinXP, potom několik let Ubuntu od 8.04 po snad 9.10
10
Bazar / Re:Sháním starší notebook pro kamaráda na web
« Poslední příspěvek od rqt kdy Dnes v 12:41:49 »Co jsem ale řešil (a řeším) - tak program, který umí ukládat ve starém formátu Excelu - XLS, nikoliv nové XLSX (nebo ODS od Libbre Office). To umí nativně MS Office do verze 2003, Libre Office to také zvládnou, ale už to není tolik kompatibilní.To same potrebuji vytvorit cca 1x mesicne. Mam kvuli tomu ve VM nainstalovane Win95 a v nem Office 2000. Z Libre office to pouze tisknu z normalni masiny. I email.cz ma docela schopny plugin pro zobrazeni. Ale tohle snad nepotrebuje ten kamarad, kteremu hledas notebook? Nebo ano a je to dalsi kriterium pro notebook?
