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
Volná diskuze / [ANKETA] SSD a vaše zkušenosti
« kdy: 20. 04. 2020, 10:31:14 »
V únoru 2014 jsem k narozkám dostal svůj první SSD disk. Byl to jeden z tehdy nejlevnějších, Adata SP600, s kapacitou 64GB/59.6GiB.
Byl jsem ovšem skeptickej, je nám totiž známo, že se jedná o stejnou technologii uchovávání dat jako na obyčejných paměťovkách nebo flashkách. Flashky mi odešly dvě, paměťovky tři, pokaždý "únavou" paměťových buněk (vydržej například jen 100 přepisů), soubory se při ukládání zmrzačily a nešly číst. No a když se vám tohle stane na dovolený v zahraničí a doma pak zjistíte, že čtvrtinu fotek máte poškozenou, zpravidla nepoužitelnou, rozhodně se vám nechce věřit, že by SSD, byť s inteligentním řadičem, měly bejt spolehlivější. Jo, třeba drahý SSD od Intelu by mohly dobře sloužit několik let, ale konzumní Adata? Vždyť za hodinu ne na disk vykonaj klidně stovky přepisů!
Ale co, rozdělil a naformátoval jsem ho na EXT4 bez optimalizace pro SSD (ani jsem o tom nevěděl), nainstaloval na něj systém (s /home na HDD), kdyby něco, na HDD bylo dost místa pro systém.
Stroj běží prakticky 24/7, alespoň jednou denně aktualizace systému, čas byl skoro plnej, když mi odešel HDD a přetáhnul jsem z něj přeživší data, poměrně často kompilace jádra a vůbec dostával zabrat.
Teď má za sebou bez půldruhýho měsíce 6 let provozu, 959x byl zapnut, krmí ho už třetí základní deska a pátej procesor. A dosud běží bezchybně, stále jako novej, i když fakt dostává zabrat.
Takže kdo váhá nad jeho koupí, nemusí, vyplatí se. Díky němu, i když je zastaralej a relativně k dnešním pomalej, systém bootuje 4s, programy se spouštěj svižně, diskový operace jsou hodně rychlý, je tichej a úspornej.

A co vy? Podělte se o svoje zkušenosti.

2
O tomto fóru / Nová sada smajlů
« kdy: 05. 04. 2020, 18:38:51 »
Když už teď můžeme zvětšovat smajly spolu s textem a když už zhruba můžeme hledět na fórum přes mobil, je blbost mít tady smajly v GIFu o rozměrech 15×15px - je rok 2020, ne 2000. Proto jsem se rozhodl pro jinou sadu.
Hledal jsem, hledal, ale většinou se jednalo o ty přeplácané, co při zmenšení na standardní velikost není poznat, co znázorňuje, a proto jsem se po čase hledání rozhodl je vzít ze sady písem Noto (balík fonts-noto-color-emoji). Jsou doostřené a trochu graficky upravené, aby i při zmenšení na 16×16px (i míň) bylo poznat, co znázorňují. A tady jsou:
:) ;) :D ;D >:( :( :o 8) ??? ::) :P :-[ :-X :-\ :-* :'(

0.6em (60%, ~9px): 8)
0.8em (80%, ~12px): 8)
1.0em (100%, ~15px): 8) <<< Standardní velikost
2em (200%, ~30px): 8)
4.2em (420%, ~64px): 8)

3
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.
Ď

4
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í.

5
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 po přezkoumání seznamu z deborphanu 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.

6
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.

7
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ší.

8
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.

9
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.

10
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 kompresním algoritmem, 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 a plynulost chodu swapujícího systému v porovnání se swapováním na disk, 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)
* Do RAM lze vměstnat i víc jak dvojnásobek její kapacity

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)
* K zpomalení 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 a systém je během swapování mnohem použitelnější

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 (přepsáno, už nepotřebujete Perl, stačí jen BASH a jeho vestavěné funkce):

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

FRAC=111
MMRY=`grep MemTotal: /proc/meminfo | awk '{print $2}'`
CPUS=`grep -c processor /proc/cpuinfo`
SIZE=$((MMRY*1024*FRAC/100/CPUS))


START() {
param=`modinfo zram | grep num_devices | cut -f2 -d: | tr -d ' '`
for n in `seq $CPUS`; do
  I=$((n-1))
  modprobe zram $param=$CPUS
  echo $SIZE > /sys/block/zram$I/disksize
  mkswap /dev/zram$I
  swapon /dev/zram$I -p 10
done &
wait
}

STOP() {
for n in `seq $CPUS`; do
  I=$((n-1))
  swapoff /dev/zram$I; echo "Odstraněn disk $n/$CPUS"
done &
wait
modprobe -r zram
}

RELOAD() {
systemctl daemon-reload
}

case "$1" in
"start") START;;
"stop") STOP;;
"restart") STOP; START;;
"reload") STOP; RELOAD; START;;
*) echo "Použití: `basename $0` (start | stop | restart | reload)" & exit 1;;
esac

2) V terminálu mu (jako root) nastavte spustitelnost:
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 12 v tom skriptu je proměnná FRAC - 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, jde to kolikrát i víc, mám 111%, musíte odzkoušet}
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.

EDIT: Na svým nynějším stroji (viz podpis) jsem udělal benchmark čtení z zRAM bloku - 11.9GB/s (80x rychlejší jak SSD)

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

11
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?

12
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

13
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.

14
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

15
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)?

Stran: [1] 2 3 ... 6