Příspěvky

16

Hardware / Re:výběr tichého ATX zdroje

« kdy: 02. 01. 2013, 15:40:34 »

Jo a zalezi kolik do toho chces dat penez.

Jako vždycky když vybírám podobná udělátka - stanovím si cenu X a pak utratím dvakrát tolik ;-)

17

Hardware / Re:výběr tichého ATX zdroje

« kdy: 02. 01. 2013, 13:42:28 »

a neslo by u stavajiciho jen vymenit ventilator?

To netuším a nemám moc chuť se v tom vrtat - předpokládám že problém bude nejenom ve větráčku ale i v tom že zdroj prostě hodně topí a má termoregulaci nastavenou tak aby se větráček hodně točil. Takže nový větráček to nevyřeší, navíc bych tak předpokládám eliminoval záruku.

18

Hardware / Re:výběr tichého ATX zdroje

« kdy: 01. 01. 2013, 19:44:40 »

Sakra, koukám že to ocitovalo nějak špatně ... tak znovu a lépe:

Možná chceš tohle:
https://www.alza.cz/enermax-triathlor-eta550awt-550w-d365212.htm
Slušnej zdroj prostě trochu něco stojí, Enermax je Enermax.

Hmm, to vypadá rozumně a je to tak na hranici kolik jsem ochoten do toho investovat. Akorát mne trochu irituje že jsem na něj nikde nenašel recenzi / test atd. A když už svoji značku na levné šunty třetích stran lepí i Seasonic ... ale tohle asi nebude ten případ. Akorát bych se prostě rád vyhnul stejné chybě jako jsem udělal u toho současného Corsaira, kdy jsem uvěřil že má "tichý větráček".

OCZ zdroje nedělá, plácá na to svou nálepku, uvnitř bude v lepším případě originál Fortron, ale spíš někdo z FSP group (Fortron Source Power Group). http://en.wikipedia.org/wiki/FSP_Group
Dost možná byl vyrobený v ČR, u nás se v licenci dělají na jedné lince Eurocese/Levné Fortrony a Seasonic.

Za cca 800 až 900 nečekej slušnej zdroj, slušné zdroje začínaly na 2000,- Kč a teď řekněme na 1500,- bez daně.

No, právě proto jsem psal že mi ta cena přijde podezřele nízká ...

Jinak nevím o žádném smrtelníkovi, který by opravdu potřeboval 500-600W zdroj, mě osobně stačí 425W zdroj, mám Core i7+32GB ram, ssd, hdd a highendovýho Radeona, co si řekne klidně o 200W. Pecko si průměrně řekne o 50 až 100W a když pustím nějakou gamesu, tak se dostanu na cca 300W. Ber to tak že to co utáhne tvůj "500W" zdroj utáhne i značková 400W s prstem v nose.

No, já vím že bych si asi vystačil s o něco slabším zdrojem, nicméně mám tam i5-2500K což zbaští cca 150W, 8 SATA disků (RAID, ...) což si vezme každý až 10W - řekněme 100W celkem. K tomu GPU - řádově 100-150W. A jsme na 350-400W (samozřejmě v reálu to bude míň, protože většinou nepoběží všechny komponenty najednou) ...

A možná se pletu, ale mám za to že hlučnost zdroje závisí i na zátěži - pokud budu cucat 350W ze 400W zdroje, mělo by to být hlučnější než když budu cucat 350W z 550W zdroje. Nebo ne?

Jestli chceš levnej a přitom kvalitní zdroj, ber:
https://www.alza.cz/enermax-triathlor-eta450awt-450w-d365211.htm

Enermax NANX nemám nejlepší doporučení, je to prý stejný šubruňk jako všechny ostatní levné zdroje.

Ten 450W zdroj je asi to samý jako ten první, jenom s o 100W menším výkonem, že? To bych asi šel do toho 550W, ten cenový rozdíl je celkem minimální a za těch 100W mi stojí.

19

Hardware / Re:výběr tichého ATX zdroje

« kdy: 01. 01. 2013, 19:43:48 »

Možná chceš tohle:
https://www.alza.cz/enermax-triathlor-eta550awt-550w-d365212.htm
Slušnej zdroj prostě trochu něco stojí, Enermax je Enermax.

OCZ zdroje nedělá, plácá na to svou nálepku, uvnitř bude v lepším případě originál Fortron, ale spíš někdo z FSP group (Fortron Source Power Group). http://en.wikipedia.org/wiki/FSP_Group
Dost možná byl vyrobený v ČR, u nás se v licenci dělají na jedné lince Eurocese/Levné Fortrony a Seasonic.

Za cca 800 až 900 nečekej slušnej zdroj, slušné zdroje začínaly na 2000,- Kč a teď řekněme na 1500,- bez daně.

Jinak nevím o žádném smrtelníkovi, který by opravdu potřeboval 500-600W zdroj, mě osobně stačí 425W zdroj, mám Core i7+32GB ram, ssd, hdd a highendovýho Radeona, co si řekne klidně o 200W. Pecko si průměrně řekne o 50 až 100W a když pustím nějakou gamesu, tak se dostanu na cca 300W. Ber to tak že to co utáhne tvůj "500W" zdroj utáhne i značková 400W s prstem v nose.

Jestli chceš levnej a přitom kvalitní zdroj, ber:
https://www.alza.cz/enermax-triathlor-eta450awt-450w-d365211.htm

Enermax NANX nemám nejlepší doporučení, je to prý stejný šubruňk jako všechny ostatní levné zdroje.

20

Hardware / Výběr tichého ATX zdroje

« kdy: 01. 01. 2013, 18:41:23 »

Ahoj,

potřebuji poradit s výběrem ATX zdroje. Aktuálně mám Corsair TX650 V2, funguje bez problémů ale začala mne dost štvát jeho hlučnost, takže hledám nějakou spolehlivou a tichou alternativu s výkonem cca 500-600W (asi by mělo stačit i trochu méně, ale chci mít rezervu). Samozřejmě za rozumnou cenu ;-)

Koukal jsem na http://www.silentpcreview.com/Recommended_PSUs ale uvedené zdroje jsou buď v ČR nedostupné (Kingwin) nebo byly zřejmě nahrazeny novými modely (Enermax) a tam se neodvažuji doporučení převádět na nové modely - všichni víme že nový model automaticky neznamená "lepší".

Koukal jsem do alzy na zdroje s hlučností pod 20 dB, a zaujal mne tam "OCZ CoreXStream 500W" (https://www.alza.cz/ocz-corexstream-500w-d328835.htm) - je fakt že ta cena je až podezřele nízká, a navíc je to na dolní hranici výkonu který bych rád. Ale zase má velmi dobrá hodnocení uživatelů ....

Nebo máte nějaká jiná doporučení?

21

O serveru Root.cz / expirace session v diskusi

« kdy: 01. 01. 2013, 18:31:23 »

Jestli je tady ve fóru jedna věc která mne brutálně točí tak je to krátká doba expirace session a to jak zvráceně je ošetřená situace při odeslání postu po vypršení. Celkem pravidelně se stává že dlouho pečlivě smolím nějaký post a při kliknutí na "odeslat" o něj kompletně přijdu protože holt vyexpirovala session.

Přitom ošetřit to rozumně není snad tak složité - např. AJAXem před odesláním příspěvku ověřit že jsem přihlášený, pokud ne tak nabídnout login přes "pop-up" formulář, a až po přihlášení odeslat formulář s příspěvkem. A nebo to řešit na serveru, tak aby se text příspěvku neztratil po přihlášení nabídnout jeho opakované odeslání.

22

Distribuce / Re:Vhodné rozdělení SSD pro Debian

« kdy: 13. 08. 2012, 16:11:28 »

swappiness nevypina swap, pouze urcuje co a kdy se odsune na swap pri "plne pameti".

To je přinejmenším nepřesné. Swappiness určuje jestli má systém radši swapovat nebo vyhazovat stránky z page cache (filesystem cache). Nastavením na 0 říkáte že systém se má swapování vyhýbat co to jenom jde, a až v okamžiku kdy v page cache není nic a jádro neví kudy kam tak se začne swapovat. Takže efektivně je to vypnutí ale systém vám nespadne.

Pokud swap skutečně vypnete (swapoff), tak dosáhnete toho samého akorát vám to v okamžiku kdy jádro nebude schopno alokovat paměť (a ani vyhodit něco z page cache) spadne na hubu.

23

Server / Re:Btrfs na server?

« kdy: 07. 08. 2012, 16:04:13 »

Já bych raději vyřešil příčinu výpadků, než obcházel důsledky...

Přesně, zejména pokud je to server. Výpadky proudu asi nevyřešíte ale UPS která zajistí alespoň korektní vypnutí se dnes dá pořídit za pár korun.

24

Server / Re:Btrfs na server?

« kdy: 07. 08. 2012, 14:54:18 »

Zdravim doteraz som pouzival Debiana squeeze s ext4, mam to na ssd disku, a casto koli vypadkom sa mi suborovy system pokazi...nejde opravit a treba preinstalovat. Rozmyslal som tam hodit btrfs, ma to vyznam alebo radsej ostat pri ext4. Je na Debian mozne pouzit btrfs?

Je potřeba víc informací - alespoň verzi jádra a jak to máte namountované (options). Každopádně btrfs asi není ta správná alternativa, zejména pro to že až do nedávna neměl vůbec žádný fsck a i dneska je to hodně experimentální.

25

Vývoj / Re:Ukladanie frame-like dát do DB

« kdy: 30. 07. 2012, 11:16:43 »

SDI

Nějaká ještě kratší a odpověď by nebyla?

Pisateľ pravdepodobne myslel http://en.wikipedia.org/wiki/Spatial_data_infrastructure

Možné to je, ale jak to aplikovat na váš problém je mi záhadou ...

Tak z pohledu teorie je ta první varianta dost neoptimální - konec konců problémy jste popsal sám. Ta druhá varianta je "správnější" a pokud chcete jít ještě o krok dál tak ji dekomponujte na dvě. V jedné bude entita "měření" s umělým PK a ve druhé (kardinalita 1:*) budou naměřené hodnoty a FK odkazující na ten umělý PK. Tj. něco jako

mereni:
Kód: [Vybrat]

|PK|Parameter1|Parameter2|Parameter3|Parameter4|Parameter5|


hodnoty:
Kód: [Vybrat]

|PK|Cislo frameu|Hodnota|


Výhoda je v tom že nebudete pořád opakovat ty parametry - budou jenom 1x v té první tabulce, v druhé tabulce je jenom ten umělý PK (typicky integer). Kolik ušetříte závisí na velikosti těch parametrů (tj. čím jsou delší tím víc ušetříte) apod.

Nevýhoda je že pro dotazování musíte ty tabulky joinovat (a nebo si vyhledat PK v první tabulce a pak se v druhém kroku dotazovat do té druhé). Jak moc to vadí závisí na tom jak to používáte.

To ma tiež napadlo, ale má to svoje problémy. Tam sa nezmestím pod 8 bytov za FK a 2 byty za cislo frameu = 10 bytov namiesto 14. Čiže problém to úplne nerieši + pridáva to komplikovanosť dotazov.

To nedokážu posoudit - zatím jste nám neprozradil o jaké datové typy se jedná, takže netuším kolik co zabírá. Navíc ony ty počty nejsou takhle jednoduché, protože některé typy mohou mít overhead kvůli dodatečnému infu (délka, přesnost, ...).

O jakých datových objemech se vlastně bavíme? O megabajtech, gigabajtech?

Další možností je využít různých specifických vlastností jednotlivých databází - např. PostgreSQL umí pracovat s poli, takže si tu tabulku můžete definovat takhle:
....

Presne v niečo takéto som dúfal, možno SDI ako bolo vyššie spomenuté. Akurát problém s MySQL.
Nemáte ešte nejaký podobný nápad? Tie polia prakticky sú to, čo potrebujem - keď manipulujem s dátami, tak už so všetkými skalármi súčasne. Pridávať nepotrebujem, to sa spraví vždy dávkou a už sa to nezväčšuje.

MySQL pokud vím žádný nativní datový typ pro pole nemá, takže si to tam budete muset serializovat ručně. Např. do BINARY nebo spíš VARBINARY.

26

Vývoj / Re:Ukladanie frame-like dát do DB

« kdy: 30. 07. 2012, 00:56:59 »

Pôjdem hneď k veci  - Potrebujem ukladať medicínske dáta, ktoré chodia vo frameoch. Viem framerate, číslo frameu a hodnotu (real, resp. DECIMAL). Pekný príklad je meranie EMG.

Takže vám postupně chodí nějaká časová řada, tj. jedna skalární hodnota (+ ty doplňující informace ukládané do sloupců Parameter1, ..., Parametr5)? Potřebujete s těmi daty pak provádět něco dalšího (např. nad nimi provádět dotazy - počítat průměr apod.) nebo je potřebujete jenom uložit?

Jakou DB vlastně používáte? MySQL, PostgreSQL, něco komerčního?

Problém je v tom, že v súčasnosti sa dáta ukladajú ako parametre (5 FK do číselníkov) a k nim sa priradí 100 hodnôt do sto stĺpcov tabuľky. Tu je ten problém, že ak je počet frameov iný ako 100, tak sa to musí dopočítať, poprípade zahodiť. Preto by som chcel spraviť presnejšie ukladanie - to jest uloži sa len to, čo sa nameralo.
Súčasná tabuľka:
|Parameter1|Parameter2|Parameter3|Parameter4|Parameter5|0|1|2|......|100|

Rozmýšľal som, že spravím nasledujúcu zmenu:
|Parameter1|Parameter2|Parameter3|Parameter4|Parameter5|Cislo frameu|Hodnota|

Tu je problém, že sa mi počet záznamov prakticky zostonásobí. Ešte dodám, že pôvodných záznamov je niečo cez jeden milión. To, že by som mal 100 mega riadkov asi prežijem, ale horšie vidím plytvanie priestorom, pretože 100-krát zopakujem všetky parametre a budem meniť iba číslo frameu a hodnotu. Súčet veľkosť parametrov nedám pod 14 bytov, čo dáva 1.4kB odpadu na jedno meranie (ak predpokladáme 100 frameov - obecne sa počet frameov pohybuje od 50 do pár stoviek). Aby ste nemuseli počítať, tak po zmene by DB narástla o cca 1.4GB 

Nejaké nápady, ako ukladať takýto typ dát?

Tak z pohledu teorie je ta první varianta dost neoptimální - konec konců problémy jste popsal sám. Ta druhá varianta je "správnější" a pokud chcete jít ještě o krok dál tak ji dekomponujte na dvě. V jedné bude entita "měření" s umělým PK a ve druhé (kardinalita 1:*) budou naměřené hodnoty a FK odkazující na ten umělý PK. Tj. něco jako

mereni:

Kód: [Vybrat]

|PK|Parameter1|Parameter2|Parameter3|Parameter4|Parameter5|
hodnoty:

Kód: [Vybrat]

|PK|Cislo frameu|Hodnota|
Výhoda je v tom že nebudete pořád opakovat ty parametry - budou jenom 1x v té první tabulce, v druhé tabulce je jenom ten umělý PK (typicky integer). Kolik ušetříte závisí na velikosti těch parametrů (tj. čím jsou delší tím víc ušetříte) apod.

Nevýhoda je že pro dotazování musíte ty tabulky joinovat (a nebo si vyhledat PK v první tabulce a pak se v druhém kroku dotazovat do té druhé). Jak moc to vadí závisí na tom jak to používáte.

Další možností je využít různých specifických vlastností jednotlivých databází - např. PostgreSQL umí pracovat s poli, takže si tu tabulku můžete definovat takhle:

Kód: [Vybrat]

CREATE TABLE mereni (
  PARAMETR1 INT,
  PARAMETR2 INT,
  PARAMETR3 INT,
  PARAMETR4 INT,
  PARAMETR5 INT,
  HODNOTY   DECIMAL[]
)
a pak do toho data vkládat jednoduše

Kód: [Vybrat]

INSERT INTO mereni
     VALUES (1, 2, 3, 4, 5, ARRAY[20000, 25000, 25000, 25000]);
případně s tím manipulovat pomocí 'array_append(pole, prvek)' apod.

U MySQL o ničem takovém nevím, komerční DB podobné věci mají (např. Oracle má varrays).

27

Vývoj / Re:Ukladanie frame-like dát do DB

« kdy: 30. 07. 2012, 00:16:33 »

SDI

Nějaká ještě kratší a odpověď by nebyla?

28

Server / Re:MySQL - převod sloupců v tabulce na řádky

« kdy: 19. 07. 2012, 23:52:51 »

2 Vondra: Pokud se nekdo zepta, "Mam kilo jablek, jak z toho udelam hruskovy kompot?" Tak se mu taky dostane odpoved, ze se pta na nesmysl a to zcela po pravu.
MySQL se snazi byt relacni databazi a vychazi tedy i z relacni algebry. Krome jineho to znamena, ze adresuji radky jejich hodnotami. Ve slusne databazove spolecnosti ma tabulka primarni klic. Pokud tabulku prevratim, tak primarni klic narvu do jednoho radku. A co pak s tim? Jak budu adresovat radky? A pokud mam ty datove struktury navrzeny tak, ze kdyz to chci joinovat, tak to musim nejdriv otocit, tak bych se mel drzet excelu nez se naucim zaklady relacnich databazi.

Tak především z původního postu není zřejmé čeho pisatelka chce dosáhnout - tudíž reakce ve stylu "je to nesmysl" jsou jaksi mimo, neboť jsou založeny na soukromých dedukcích pisatelů. Ano, může se ukázat že dotaz plyne z nepochopení nebo že je špatně navržený datový model (a podle dalšího postu to tak vypadá), ale z toho počátečního postu to skutečně jasné není.

Co se primárních klíčů týká - ano, je takovým pěkným zvykem že tabulky mají primární klíče. Poněkud mi ale uniká jak z toho plyne že pivotace je obecně nesmysl. Když si vezmu např. 2x2 kontingenční tabulku která je výsledkem dotazu SELECT pohlavi, SUM(CASE barva_vlasu WHEN 'blond' THEN 1 ELSE 0 END) AS blond, SUM(CASE barva_vlasu WHEN 'blond' THEN 1 ELSE 0 END) AS not_blond FROM lidi tj. něco jako

pohlaví	blond	not_blond
muž	65	91
žena	41	63

tj. vlastně relaci na doménách [pohlaví, počet osob, počet osob], tak co je tak zavrženíhodného a nelogického na transformaci

barva vlasů	muž	žena
blond	65	41
not blond	91	63

tj. vlastně na relaci na doménách [barva vlasů, počet osob, počet osob]? Mj. si dovoluji poznamenat že obě ty relace mají primární klíče.

29

Server / Re:MySQL - převod sloupců v tabulce na řádky

« kdy: 19. 07. 2012, 23:18:36 »

Aha, no ale to skutečně zní hodně divoce - můžete uvést příklad (byť zjednodušený) jak ty tři tabulky vypadají (strukturu a pár záznamů)?

Totiž pokud vezmu že ta tabulka má sloupec "name_col" ve kterém jsou nějaká jména (řekněme lidí) a další sloupec, tj. vypadá to např. takhle:

Franta	10
Jirka	20
Honza	1
...	...

tak přeci "pivotováním" vznikne něco takovéhoto:

Franta	Jirka	Honza	...
10	20	1

tj. "cosi" (relace to skutečně není) o dvou řádcích a neurčitém počtu sloupců. A nenapadá mne jak bych to joinoval a co bych tím získal ...

30

Server / Re:MySQL - převod sloupců v tabulce na řádky

« kdy: 19. 07. 2012, 13:04:07 »

LOL. Někdo se tu zeptá "Jak udělat X?" a dostane se mu odpovědí že vlastně chce úplný nesmysl, případně že "čisto teoreticky sa to spraviť dá" ale jaksi bez informace jak. Přitom pivotace je v mnoha aplikacích celkem běžně používaná záležitost, i když ne vždy se provádí kompletně v DB (někdy je prostě jednodušší to udělat na klientovi nebo v nějaké mezivrstvě). Každopádně pokud se mluví o pivotaci, tak se v drtivé většině případů používá na AGREGOVANÁ data, a to do konečného počtu skupin (např. pevně dané věkové skupiny apod.), takže námitky že neurčitý má být počet řádků jsou mimo ...

Mirko, napište jak vypadají data, proč je chcete pivotovat a proč vám návody dostupné na netu (např. http://datacharmer.org/downloads/pivot_tables_mysql_5.pdf nebo http://en.wikibooks.org/wiki/MySQL/Pivot_table).