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.


Témata - Roman Horník

Stran: [1] 2 3 ... 6
1
Složitá situace pro vývoj. Máme tady zařízení s velkým i malým zobrazovátkem s velkým i malým dpi (jemností zobrazovacích bodů) a máme tady konsorcium W3C, který sice vychrlilo kvantum dýlkových jednotek pro určení rozměrů objektů webový stránky, třeba písma, ale je to těžký, když se například milimetr (centimetr, palec aj.) odvíjí nikoliv od fyzickýho rozlišení displeje, ale od fixního rozlišení 96dpi, takže se takovej centimetr, když si zvolím, na mým monitoru s 94dpi zobrazí jako 1.02cm (skoro přesně), ale na mobilu s rozlišením 400dpi jako 0.24cm. A když někdo má na starým stroji na 19" monitoru rozlišení jen 640×512 (5:4), pak má z centimetru 2.2cm, jinak řečeno, když zvolím nějakou velikost písma, na mobilu a na dalších zařízeních s prťavoučkým pixelem (a ještě k tomu kolikrát nečtvercovým), písmo nebude čitelný, zato na monitorech s VGA rozlišením bude obrovský. Nevím, kde soudruzi z NDR udělali chybu, ale prohlížeče už pěknou řádku let znaj jak rozměry svýho okna i celý obrazovky v pixelech, tak i rozlišení monitoru v DPI, z čehož se daj dopočítat fyzický rozměry v mm/cm/"/….
Nějak jsem ty rozměry v rámci možností nadefinoval, aby se mi zobrazovala stránka dobře jak na 24" FHD monitoru, tak i na 5" shitphonu s HD rozlišením (720×1280, cca 280dpi), ale víc zobrazovátek, teda ještě krom televize, nemám. Ale vy jo. A proto vás prosím, nějak se mi k tomu vyjádřete a ideálně k tomu napište, o jaký zařízení, jeho výrobce a model se jedná (nebo parametry, pokud znáte), a jak to na nich funguje.
Jde mi o to, aby se vám s fórem pracovalo co nejlíp.
Ď

2
O tomto fóru / Fórum dostalo nový kabát
« kdy: 02. 04. 2020, 01:12:47 »
Po dohodě s Otou jsem se jal učunit novou vizáž fóra, jíž jsem dal název <I/O>.
Ačkoliv jako základ bylo zvoleno téma předchozí, VDW, bylo natolik překopáno, že z původního prakticky nic nezbylo, navíc je o dvě třetiny menší, s optimalizovaným kódem a používá obrázky jen v nejnutnějším případě (ikonky a smajly, na pozadí a v logu je SVG).
Nově koketuje s technologiemi HTML5 a CSS3, ale také s responzivitou (de facto extra zobrazení pro mobily a vůbec zařízení s malým displejem s vysokou hustotou pixelů na jednotku plochy - aktivuje se od rozlišení alespoň 120dpi; kdyby měl někdo lepší nápad, sem s ním), která byla napsána od píky s důrazem na dobrou čitelnost a použitelnost i u malých displejů a velkých palců.
<I/O> je stále ve fázi vývoje, desktopová verze se pouze dolaďuje, mobilní chce dotáhnout pořádněji.
Doufám, že se vám <I/O> líbí.

3
Při správě softwaru, tj. instalaci, odinstalaci nebo aktualizaci, se sem tam stane, že u balíku jsou pozměněny závislosti, kdy přestane záviset na jednom a naopak si vyžádá balík jiný. Ideálně by se přebytečný balík měl odstranit, nebo alespoň nabídnout k odstranění, avšak málokdy tomu tak je. A tak si po čase udržujeme a aktualizujeme balíky, zpravidla knihovny, co jsou nám i softwaru naprosto k ničemu.
Nejde tady o místo, taková knihovna má obvykle pár desítek kilobajtů, avšak mívá svoje závislosti a kvůli nim nainstalované další a další  zbytečné balíky. Mimo to, občas se stane, že některý z těchto balíků blokuje aktualizaci jiného, který s ním nemá nic společného, neboť může mít v závislostech některý z pro systém důležitý balík (třeba libc6) konkrétní verze.
Když jsou závislosti balíku určeny řádně, správce balíků nám přebývající nabídne k odstranění, jenže, protože je realita jiná, je vhodné se jich zbavovat alespoň ručně. Pro tenhle účel se dobře hodil program gtkorphan, avšak jeho vývoj byl dávno ukončen a žádnou jeho adekvátní grafickou náhradu jsem nenašel.
Nicméně pro textové prostředí existuje gtkorphan. Jeho úkolem ovšem není přebytečné balíky odstranit, ale pouze zobrazit, proto jeho výstupem, seznamem zbytečných balíků, musíme nakrmit apt/apt-get/aptitude - tak třeba apt (syntaxe je u jiných stejná):

# apt purge `deborphan` # obrácený apostrof se zadává pomocí [R-Alt]+[H]. Místo `deborphan` můžete použít $(deborphan)

Protože deborphan nezkoumá závislosti přebytečných balíků, po dalším spuštění příkazu se mohou objevovat další, proto v případě potřeby opakujte. Rovněž vám může apt{-get|itude} nabídnout další balíky k odstranění, tyto se odstraní příkazem:

# apt autoremove

Tohle mi párkrát pomohlo, když zbytečný balík blokoval aktualizaci několika jiných z důvodu výše uvedeného.

4
Správa aplikací / GIMP 2.10.xx a segfault: řešení
« kdy: 17. 03. 2020, 01:31:09 »
Už chvíli mi nefungoval GIMP, házel při načítání pluginů segfault a ukončil se. Zkoušel jsem vedle verze 2.10.14-2+b1 starší verzi 2.10.12-1, ale némlich to samý. Pro mě je to klíčovej program, dělám grafiku, proto jsem se se současnou situací nespokojil.
Na tohle téma existuje spousta chybových hlášení, většinou je za řešení považováno získat nejnovější zdrojáky z GITu a zkompilovat je. Do toho se mi nechtělo, muselo by se stáhnout mnoho balíčků s hlavičkama, což by zabordelilo akorát systém, kde mám jen a pouze to, co potřebuju nebo z nějakýho důvodu nemůžu odstranit.
Našel jsem alternativní řešení, jednoduchý a rychlý, akorát zmizí jeden málo používanej plugin na ohnutí rohu obrázku. Ten plugin se jmenuje pagecurl a nachází se ve složce /usr/lib/gimp/2.0/plug-ins/pagecurl/, kterou stačí buď přemístit jinam, nebo rovnou odstranit. GIMP pak funguje normálně.
Jakmile přijde aktualizace, složka s opraveným pluginem by se měla doplnit.

P. S.: Tak je to ještě složitější, GIMP zbouraj i balíky gimp-gap a gimp-plugin-registry. Bez nich funguje, gimp-gmic a gimp-python jsou v pořádku. Vypadá to tedy, že je chyba přímo v GIMPu.

5
Před pár lety se provalily bezpečnostní trhliny procesorů nejen výrobce Intel, jež byly nazvány Spectre a Meltdown. Od tý doby jich bylo nalezeno víc - viz lscpu. Opraveny byly softwarově obvykle vyřazením některých funkcí CPU, čímžto se v některých případech poměrně citelně snížil jejich výpočetní výkon.
Protože existuje prakticky nulový riziko napadení vašeho stroje a zneužití těchto trhlin, zpravidla způsobujících pouhý zatuhnutí systému, můžeme si je v klidu znovu povolit. Nárůst výkonu je v některých případech až kolem 10-20%. Jak na to?
Stačí spustit systém s jaderným parametrem mitigations=off, například přidáním tohoto parametru na řádek GRUB_CMDLINE_LINUX a následným spuštěním update-grub - změny by se měly projevit po restartu. Systém bude i nadále zcela stabilní, avšak o něco živější.

6
Volná diskuze / Iceweasel > Firefox?
« kdy: 11. 03. 2016, 20:00:34 »
Nevím, jestli jste to vy, co máte Sida, zaznamenali, ale balík iceweasel (vč. jazykových balíků) od verze 45.0 se stal metabalíkem instalujícím balík firefox-esr, a dále je k dispozici i "normální" balík firefox a k nim jazykový balíky ve formátu firefox-l10n-<něco>, respektive firefox-esr-l10n-<něco>.

Tak se mi zdá, že Iceweasel, kosmetická upravenina Firefoxu, už nebude potřeba.

7
Volná diskuze / Zemřel Ian Murdock
« kdy: 31. 12. 2015, 06:59:36 »
Už jsem se o tom vypsal tady. Pro mně to je hodně špatná zpráva, Debian, dílo, co on započal, mám moc rád. A nečekal jsem, že tak inteligentní člověk udělá takovou, s prominutím, píčovinu.

8
Správa, údržba a nastavení systému / ▶ Swapujme do RAM
« kdy: 20. 12. 2015, 00:02:43 »
Zní to jako šílenej paradox, vždyť swap je přece nástavbou RAM, když její kapacita už došla, když už se do ní nic nevejde. Ale jde to, jde to vskutku velice dobře.
Píšu tady o zRAM, principem činnosti je komprese stránek uložených v RAM algoritmem LZ4, jinými slovy, do RAM se vejde víc dat, než za normálních okolností dokáže pojmout. Na Debíkovi je tato vlastnost k dispozici od jádra verze 3.2, využívá se u operačních systémů Android.

Výhody:
* Mnohem vyšší rychlost v porovnání se swapováním na disk a mnohem nižší, prakticky zanedbatelné latence (nikde neběhá rameno s hlavičkami a nehledá stopu na disku)
* Nechrochtá jako swapující disk, ba naopak, takovýto způsob swapování je absolutně neslyšný
* Je schopen využít všechna jádra CPU, čím víc jader, tím vyšší výkon
* Šetří disky. DRAM se neopotřebí (přestože stále pracuje na plné obrátky), zatímco mechanismus HDD dostává dost na prdel a flash paměť SSD má omezený počet zápisů a přepisů na buňku (tam je čtení, zápis a navíc i přepis; čtení nic nepoškozuje)

Nevýhody:
* Kdo chce uspávat na disk, stejně logicky swapovací oddíl na disku potřebuje; jak se RAM vypne šťáva, není schopna uchovat data (kromě logických nul)
* Rychlost je závislá především na rychlosti CPU
* K sekání běhu systému a aplikací stejně dochází, komprese i dekomprese zabírají všechen dostupný procesorový čas. Jen to trvá mnohem kratší dobu

Následující postup byl převzat a počeštěn z wiki Debianu a je mnou velmi dobře odzkoušený:



1) Vytvořte soubor /etc/init.d/zram a nasypejte do něj:

Kód: [Vybrat]
#!/bin/sh
### BEGIN INIT INFO
# Provides:          zram
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Default-Start:     S
# Default-Stop:      0 1 6
# Short-Description: Use compressed RAM as in-memory swap
# Description:       Use compressed RAM as in-memory swap
### END INIT INFO

# Author: Antonio Galea <antonio.galea@gmail.com>
# Thanks to Przemysław Tomczyk for suggesting swapoff parallelization

FRACTION=75

MEMORY=`perl -ne'/^MemTotal:\s+(\d+)/ && print $1*1024;' < /proc/meminfo`
CPUS=`grep -c processor /proc/cpuinfo`
SIZE=$(( MEMORY * FRACTION / 100 / CPUS ))

case "$1" in
  "start")
    param=`modinfo zram|grep num_devices|cut -f2 -d:|tr -d ' '`
    modprobe zram $param=$CPUS
    for n in `seq $CPUS`; do
      i=$((n - 1))
      echo $SIZE > /sys/block/zram$i/disksize
      mkswap /dev/zram$i
      swapon /dev/zram$i -p 10
    done
    ;;
  "stop")
    for n in `seq $CPUS`; do
      i=$((n - 1))
      swapoff /dev/zram$i && echo "disabled disk $n of $CPUS" &
    done
    wait
    sleep .5
    modprobe -r zram
    ;;
  *)
    echo "Usage: `basename $0` (start | stop)"
    exit 1
    ;;
esac

2) V terminálu spusťte (jako root):
chmod +x /etc/init.d/zram

3) Systému řekněte, aby se skript automaticky spouštěl při jeho startu (zase jako root):
insserv zram

4) A rovnou si to můžete spustit (opět spusťte jako root):
service zram start
nebo
/etc/init.d/zram start

Nakonec pár poznámek:
1) Na řádku 15 v tom skriptu je proměnná FRACTION - je to hodnota v procentech, a tou se nastavuje, jak velkou část z RAM použít pro zRAM swap použijte číslo v intervalu {1..100}
2) Pro swapování má zRAM vyšší prioritu jak normální swap na disku, čili nejdřív se bude při zaplnění RAM plnit zRAM swap, až potom ten na disku
3) Nebojte se, že přijdete o možnost uspávání na disk, ta priorita pro uspávání neplatí, odkládací oddíl na disku je přednější


Nakonec pár měření na mém téměř muzejním stroji:

Konfigurace:
CPU: Intel Pentium Dual-Core E2180 (2 jádra, 2.0GHz, 800MHz FSB), přetaktováno na 2.64GHz, 1.05GHz FSB
Mámoprkno: Aušus P5QPL-AM (G41 + ICH7)
RAM: 2x 1GiB DDR2, 800MHz, přetaktováno na 874MHz
SSD: ADATA SP600, 64GB/59.6GiB (novej)
HDD1: Western Digital WD3200AAKS, 320GB/298GiB (starej)
HDD2: Seagate Barracuda ST380817AS, 80GB/74.5GiB (starší)

Benchmark spáchán programem gnome-disks při odpojených oddílech a za výchozího nastavení benchmarku

Kód: [Vybrat]
      Čtení [MB/s]   Zápis [MB/s]   Přístupová doba [ms]   %zRAM (R+W)   R+W [MB/s]
zRAM    2110.0         2540.0              0.00               100.00       4650.0
SSD      270.0           78.4              0.13                 7.49        348.4
HDD1      94.5           84.7             15.36                 3.85        179.2
HDD2      48.3           46.6             12.75                 2.04         94.9

Tady je vidět, že co do všech parametrů nemá konkurenci ani u SSD.

Tak ať vám slouží, fakt to stojí za to! ;)

9
Všeobecná podpora / Blender - transformace rotace
« kdy: 30. 10. 2015, 20:17:19 »
Zdar,

nemá někdo tucha, jak udělat následující?
Jestliže dojde k rotaci předmětu (nebo kostí) A v ose X, pak chci, aby byl předmět/kost B co do rotace spřaženej, ale aby rotace neprobíhala ve stejný ose, což umím, ale v ose jiný (Y, Z).
Jak na to?

10
Nedávno se zavedla blbost s podepisováním doplňků, samozřejmě, pokud vývojář zaspí, jeho dílo náhle zablokuje prohlížeč. Mně se to stalo třeba u AdBlock Plusu, blokovači reklam.
Každej problém má svoje řešení, takže i tenhle:

1) V prohlížeči do adresního řádku zadej about:config a přejdi na ni
2) Vyhledej si tam položku xpinstall.signatures.required a dvojklikem změň hodnotu na "false"

Hotovo

11
Všeobecná podpora / Hugin - enblend odmítá poslušnost
« kdy: 27. 09. 2015, 11:43:57 »
Nazdar, už přes měsíc se s prominutím seru s Huginem verze 2015.0.0.cdefc6e53a58, nástrojem na tvorbu panoramatických snímků, kde poslední dobou prolínač enblend verze 4.1.3+dfsg-2 odmítá sloužit.
Načtu si snímky, napíchám do nich kontrolní body, pohraju si s expozicí, paráda. Dám to slepit, přemapovač teď mimochodem umí používat GPU, takže se přemapování výrazně zkrátí bez evidentní ztráty na kvalitě výsledku, a pokud použiju jako prolínač ten zabudovanej, kterej prakticky neprolíná a nechává za sebou ošklivý švy, obrázek je na světě. Ale jak použiju enblend, nehledě na nastavení programu, tak když na něj přijde řada, vyhodí to dialogový okno s chybou, kde je možnost uložení chybový zprávy, a s odkazem, kam můžu bugreport poslat.
Jenže tam nic zajímavýho není, jen průběh (tohle je anglicky; očekával jsem větší výřečnost jak u češtiny, ale je to stejný):
Kód: [Vybrat]
============================================
Stitching panorama...
============================================

Platform: Linux 4.1.0-2-686-pae i686
Version: 2015.0.0.cdefc6e53a58
Working directory: /home/roman/Desktop/YE/00
Output prefix: 20150919_164418 - 20150919_164425

Blender: enblend 4.1.3
ExifTool version: 10.00

Number of active images: 3
Output exposure value: 13.9
Canvas size: 2994x3461
ROI: (232, 52) - (2762, 2679)
FOV: 54x61
Projection: Rectilinear(0)
Using GPU for remapping: true

Panorama Outputs:
* Exposure corrected, low dynamic range

Remapped Images:
* Exposure corrected, low dynamic range

First input image
Number: 0
Filename:
Size: 2560x1920
Projection: Normal (rectilinear)
Response type: custom (EMoR)
HFOV: 47
Exposure value: 12.8


Remapping LDR images...
nona: using graphics card: NVIDIA Corporation GeForce GTX 650/PCIe/SSE2
Multiple images output
loading 20150919_164418.jpg
remapping 20150919_164418.jpg
saving 20150919_164418 - 20150919_1644250000.tif
loading 20150919_164422.jpg
remapping 20150919_164422.jpg
saving 20150919_164418 - 20150919_1644250001.tif
loading 20150919_164425.jpg
remapping 20150919_164425.jpg
saving 20150919_164418 - 20150919_1644250002.tif

Blending images...

Tohle poslat nikam nemůžu, vždyť tam prakticky nic není. Ale má s tím někdo zkušenosti? Nafotil jsem neopakovatelnej okamžik, demolici, ale takhle to nemůžu zveřejnit.

12
Zrovinka jsem řešil zapeklitej problém s ručně instalovaným balíkem ovladače termotiskárny Epson TM-T20. Samo, že tenhle návod by mohl pomoct vyřešit průsery jinejch balíků, kdy se správa softwaru přes apt-get, Aptitude, Synaptic, nebo něco jinýho stane nepoužitelnou.
Epson poskytuje ovladače přímo na svý stránce, jsou to archivy obsahující krom licenčních keců hlavně DEB a RPM balíky, PPDčka pro CUPS a skriptík, kterej by to všechno měl nainstalovat. Místo Debiana je tam sice Blbuntu, ale to je jedno, instalace možná je.
Aniž bych si uvědomil, že jsem předtím zapomněl nainstalovat CUPS, že ani ten skriptík, ani závislosti balíků se o jeho instalaci nepostaraj, skriptík jsem spustil. Instalace proběhla v pořádku, ovšem zdánlivě. Chvíli po tom jsem zjistil, že mám totálně rozmrdanou správu balíků, že není možný krom aktualizace databáze balíků dělat s balíkama nic, vlastně tak nějak to šlo, ale skončilo to vždycky chybovou hláškou, jako že ten balík má nesplněný závislosti.
A tak si říkám, že prostě ty balíky odinstaluju, nainstaluju CUPS a hned na to ovladač. Přes aptitude ani apt-get to nešlo, ale pomocí přiloženýho skriptíku na odinstalaci to šlo, taky, co jsem koukal, používá dpkg. Ale tím se odinstaloval jeden balík a druhej zůstal, podle aptitude v tuze nekonzistentním stavu. A tak to šlo dokola, žádný mně známý řešení nepomáhalo. Taky tohle se mi stalo snad poprvý za skoro 10 let, co linuxuju. I vzpomněl jsem si na Googla a získal jsem příkaz, kterej to vyřešil, kterej ten balík, se kterým se nedalo hnout, odinstalovat. Jo a používá dpkg.
Jako root spusť:
# dpkg --remove --force-remove-reinstreq název_balíku

13
Hardware / Starej disk Seagate ST380215A
« kdy: 26. 06. 2015, 13:44:09 »
Nazdar,

na stařičkým Optiplexu GX-150 provozuju kamerovej server. Kompiloval jsem na něm jádro a že ho hned vyzkouším. Po SSH mu pošlu reboot a čekám, až naskočí, až začne chrlit obrázky. A ono nic. A tak si říkám, že jsem to někde asi zprasil, tak vylezu na půdu, snesu ho dolu, píchnu na monitor a příkazovka GRUBu. Tak jsem nabootoval ručně. A aniž bych spouštěl update-grub (zkoušel jsem ho na starým jádře), po restartu do novýho jádra GRUB naskočil a systém nabootoval. I nedalo mi to a kouknul jsem se na údaje ze SMARTu (jsou to decimální čísla):
Read Error Rate: 120266766
Seek Error Rate: 165861026
Hardware ECC Recovered: 234334756

hodnoty posledních 2 položek rostou

ALE:
Reallocated Sector Count: 0
Spinup Retry Count: 0
High Fly Writes: 0
Current Pending Sector Count: 0
Uncorrectable Sector Count: 0
UDMA CRC Error Rate: 0
Write Error Rate: 0
Data Address Mark Errors: 0


Tak co si o tom mám myslet? :o Je ten disk provozuschopnej, nebo mám očekávat, že za chvíli odejde do kytek? Naběháno má jen 7 a půl měsíce a nerad bych teď sháněl nějakej starej, ale dostačující disk, mám totiž k dispozici akorát starýho 20GB Maxtora, kterej je jednak pomalej a jednak řve jak pila.
Něco podobnýho jsem totiž viděl u disku (od WD), kterej z ničeho nic začal po 3 letech a 1 dnu ztrácet data, až z něj nešlo kvůli poškozenejm oddílům ani číst, ale po ňákejch 2 tejdnech odpočinku, když jsem z něj chtěl vyhrabat data, byl zase zdravej a běží doteď. Jestli to je podobnej případ...
Jak to vidíte vy? Mám tyhle chyby přehlížet, jako že nic nehrozí, nebo mám udělat novou instalaci na cirkulárku Maxtora (respektive sehnat jinej disk)?

14
Programování / C: usleep()
« kdy: 13. 05. 2015, 20:22:15 »
Nazdar,

na starý kolena jsem byl nucen utkat se s Céčkem. Potřeboval jsem upravit jeden program, což se mi kupodivu povedlo, ačkoliv ta úprava není zrovna triviální a Céčku rozumím jak koza petrželi.
Mám potíže s usleep(), totiž očekával jsem od něj nějakou přesnost a ne, že nastavím prodlevu 1000µs (1ms) a ve skutečnosti bude třeba 915µs (měřeno pomocí bashovýho time; zabalil jsem inkriminovanej kód se čtyřma prodlevama 1ms do cyklu for() a nechal pomocí něj vykonat 10000 iterací - namísto 40s to běželo jen 36.6s), při delších prodlevách jsou skutečný prodlevy naopak delší jak nastavený (třeba 50ms > 54ms).
Proto se ptám, nedá se zajistit prodleva přesnější (třeba odvozená z taktu procesoru, FSB aj.)?

15
Volná diskuze / CUDA/OpenCL a Debian
« kdy: 07. 09. 2014, 00:00:46 »
Nazdar, jak jsem tak koukal do repa, co se tejče těchhle fičur (CUDA a OpenCL), repo nabízí prakticky jen desítky knihoven, pak programy Suricata, Pyrit a BOINC. A to je vlastně všechno. No, okrajově to umí použít Blender.
BOINC teda mám, používám ho jako přídavný topení, když mi je zima. Jak se rozjede dvoujádro přetaktovaný na 127% (dál je to kvůli limitu FSB procesoru nepoužitelný) a GPU, teplíčka je z toho dostatek.
A tak co s mejma 384 CUDA jádrama (GTX650)? Viděl bych jejich využití třeba při zpracování grafiky, videa (paralelní zpracování mnoha snímků najednou), ale taky i zvuku (několik kanálů naráz), jádro je může využívat tam, kde není potřeba řešit co nejnižší latence; něco takovýho už bylo, ale je to evidentně mrtvý. V serverech by se taky mohlo najít využití.
Ale proč nic takovýho nenacházím?
Možná se ptám zbytečně, když většina aplikací umí využít jen 1 jádro CPU, například Audacity, kde se jeden a ten samej filtr použije nejdřív na jednu stopu, pak na další, pak na další atd. - zářnej to příklad.

Stran: [1] 2 3 ... 6