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.


Příspěvky - Logik

Stran: 1 ... 48 49 [50] 51 52 ... 68
736
Software / Re: Příprava obrázků pro Word v Latexu
« kdy: 18. 05. 2011, 18:31:26 »
Na čárovej grafbitmapa naprosto stačí, anžto bude malinká i ve velkym rozlišení. Takže v tom problém IMHO na 99.9% nebude. V každym případě napsat radu bez odůvodnění je nanic. A práce s eps ve wordu je taky nicmoc, osobně bych radši použil PNG.

737
Software / Re: Příprava obrázků pro Word v Latexu
« kdy: 18. 05. 2011, 17:10:52 »
kriegel: to je v podstatě totéž, co ona dělá, akorát přes jinej formát. Pokud nevíme, co přesně je špatně, tak jak můžeš vědět, že jinej formát fungovat bude....

738
Software / Re: Nástroj na resize partitions bez ztráty dat
« kdy: 18. 05. 2011, 14:35:46 »
Přepsal jsem je, bootovat jde i z logické:
http://www.goodells.net/multiboot/
ale je to trochu trikové

739
Software / Re: Nástroj na resize partitions bez ztráty dat
« kdy: 18. 05. 2011, 14:27:38 »
Ten Tvůj postup má jedinej problém.... Do místa po swapu se mu předpokládám data z homu prostě nevejdou.... Možná by to šlon ějakym žonglováním typu zmenším home, udělám na konci další partition, tam dám půlku home/opt a zbytek by se už do swapu mohl vejít, nebo nejdřív zkopíruju opt do home, opt zruším apod.... Ale pokud nemá na disku moc místa, tak to prostě bez externího úložiště nepůjde.

Pokud má plnej disk, pak je ještě jedno dobrý řešení: koupit druhej disk a naisntalovat winy na něj...

740
Software / Re: Nástroj na resize partitions bez ztráty dat
« kdy: 18. 05. 2011, 13:54:46 »
windows do prvních 137GB byla záležitost 48LBA, od tuším SP2 omezení padlo.
Lze bootovat i XP z primární partition, ale je to trochu trikové to nastavit. 
http://www.goodells.net/multiboot/

Vzhledem k tomu, že na extended předěláš swap, tak ale bys musel hejbat se všema partition. To bych ale určitě bez zálohy nedělal. A když už budeš dělat zálohu, tak je jednoduší data někam zkopírovat a oddíly udělat znovat tak, jak potřebuješ....

Pak je ještě jedna možnost, teda jestli máš silný nervy,
pomocí Gparted zkrátit home
http://www.ranish.com/part/
1) zazálohovat si partition table :-)
2) zeditovat partition tabulku tak, že na začátku swap vytvoříš primární partition s koncem
na konci homu, v ní uděláš tři logický partition se swapem, homem a optem tak, že home a opt budou začínat tam, co dřív. Ranish nepřepisuje bootrecordy atd..., jen edituje partition table, takže bys měl mít data v těch partition v pořádku

Ale je to bez záruky, že se něco....




741
Software / Re: Příprava obrázků pro Word v Latexu
« kdy: 18. 05. 2011, 12:31:35 »
No to je IMHO správná cesta (přinejmenším jedna ze správných). Chtělo by to zjistit, kterej krok to rozmaže.

Občas bejvá při vkládání obrázku do wordu je třeba použít funkci vložit jinak, v tom by mohl bejt problém.



742
Software / Re: Paměťové nároky u fsck (ext4)
« kdy: 12. 05. 2011, 11:51:32 »
Neříkej, že ta aplikace nemá více adresářů? Udělej víc FS a jeden master FS, ve kterym dáš symlinky na jednotlivý filesystémy tak, abys rozdistribuoval zátěž.  Výhoda bude, že budeš moci rozdělit i disky mezi víc raid polí atd...
 
no a nebo ten aufs, tam bych se ale trochu bál, že když se něco pokazí, tak se to pokazí pořádně...

743
Hardware / Re: Co si mám vylepšit v serveru?
« kdy: 11. 05. 2011, 15:09:43 »
To vystavování hlaviček Greenu jdevypnout, tuším snad nějakou utilitkou od WD, ale už si to nepamatuju, pohledejte na netu.
Prskot jako procesor do furtběžícího homeserveru je imho blbina, ten žere jak sviňa. To nemusíš měřit, abych Ti řek, že daleko víc, než se Ti bude líbit... :-( Např.
http://www.zdnet.co.uk/reviews/cpus-desktop/2004/08/24/processor-benchmarks-intel-versus-amd-39164010/

744
Server / Re: U PHP skriptu nefungují náhledy
« kdy: 11. 05. 2011, 15:00:01 »
Já sem se setkal s tím, že nefungovaly náhledy s php :-)

745
Vývoj / Re: MySQL a použití sloupce ID
« kdy: 11. 05. 2011, 12:14:14 »
RowId je innodb vždy, i když je definován primární klíč, akorát neviditelně. Pokud je definován unique klíč a ne primární klíč, je clusterován ten unique klíč - ale tady jsme se bavili o rozdílu složený versus jednoduchý pkey. Deklarace tedy zabere více místa na disku (a tedy i v paměti).

Co se týče vyhledání dat, tak ta se budou vždy vyhledávat podle indexu a zajímat nás budou pouze data z indexu, takže je vyhledávání stejně rychlé s existencí i bez existence autoinkrementního políčka (v Mysql).

Co je výhodnější pro updaty je ale vlastně otázka, protože sice update clusterovaného indexu je jednodušší s jednoduchým klíčem, ale zas tam je o index navíc...

746
Vývoj / Re: MySQL a použití sloupce ID
« kdy: 10. 05. 2011, 14:55:28 »
V postgreSQL je podobný mechanismus,
http://www.postgresonline.com/journal/archives/10-How-does-CLUSTER-ON-improve-index-performance.html
ale musí se to dělat částečně manuálně.

747
Vývoj / Re: MySQL a použití sloupce ID
« kdy: 10. 05. 2011, 14:51:28 »
No, s většinou jsem možná přestřelil, ale Innodb to tak má
http://me.in-berlin.de/doc/mysql-doc/manual_InnoDB.html
(hledej clustered index)
MS SQLServer taky s opt-outem
http://msdn.microsoft.com/en-us/library/aa933131%28v=sql.80%29.aspx
a Oracle s opt-inem. Postgresql co vím nikoli.


748
Vývoj / Re: MySQL a použití sloupce ID
« kdy: 09. 05. 2011, 02:06:10 »
Ještě je jedn důvod, proč použít primární klíč. Většina databázových engine, innodb nevyjímaje, používá fyzické řazení záznamů dle primárního klíče. Pokud se tedy tabulka hodně mění, tak umělý primární klíč (furt rostoucí do nekonečna) zajistí, že se při inzetru nebudou tak často muset štěpit stránky. Zápis na konec je vždy jednodušší, než doprostřed.

Výhoda složeného klíče by byla při stabilní tabulce, ale protože většina enginů umí použít přímo data z klíče, nebude muset datovou oblast číst vůbec, takže tato výhoda padá.

749
Vývoj / Re: MySQL a použití sloupce ID
« kdy: 08. 05. 2011, 23:44:48 »
Význam těch dvou indexů je čistě jen takový, že si optimalizátor podle statistik může vybrat,, kterej použije. Jinak je to nämlich to samý, jako by tam byl jen jeden index.

Jestli je index UNIQUE nebo ne v optimalizaci příliš nehraje roli, v podstatě jediný význam je ten, že optimalizátor ví, že když zvolí tendle index, tak získá pouze jednu řádku. To ale s rozumně aktuálnáíma statistikama bude vědět taky.

Btw., ono když už mám index, tak je (skoro) vždycky rozumný ho udělat přes víc sloupců, každá rozumná databáze umí použít z vícesloupcového indexu začátek a rozdíl ve velikosti indexů není takový.



750
Vývoj / Re: MySQL a použití sloupce ID
« kdy: 06. 05. 2011, 21:58:45 »
pecko: On je index něco jako trpaslík? Ehm? Že jsi ho viděl v akci?

Zajímalo by mě, jak se to provádí. Mám dva indexy, jeden z nich použiju a vyselektnim nějaký řádky. Pak mám možnost: buďto všechny vyselektěný řádky porovnám na druhou podmínku: to má složitost n*s, kde n je počet záznamů odpovídají první podmínce a s je složitost zjištění druhé podmínky.
Anebo vyselektím záznamy pomocí druhého indexu, ty pak ale ještě musím setřídit podle prvního indexu a mergnout. Složitost je tedy
m*(log m) + m + n
kde m je velikost složky druhého indexu. Pokud má db dobře statistiky, tak je navíc m >  n. I při ideálním případě (m=n) se to ale vyplatí jen v případě, kdy složitost porovnání druhé podmínky je řádově větší než log(m)+2, spíše ani tak ne, protože to vyžaduje více paměti na zpracování a tedy to víc zatíží paměťový subsystém.

tomas:
Lidi nenadávaj na mysql kvůli tomu, že dělaj blbej návrh (i když někdo asi taky), ale proto, že veškerý složitější věci jsou v ní problém. Namátkou
Triggery: jsou. Ale nedaj se použít, protože se spustěj jen někdy. Navíc nemůžou bejt dva.
Fulltex: je. Ale nedá se použít, protože je jen nad netransakčníma tabulkama.
CTE: nejsou
Transakce: jsou. Ale implementace vyšších stupňů izolace je přinejmenším podivná (pro jistotu se všechno zamkne)
atd....

Mysql je dobrá jako jednoduché úložiště dat. Pro složitější věci se ale prostě nehodí...

Stran: 1 ... 48 49 [50] 51 52 ... 68