61
Vývoj / Re: Smalltalk v praxi
« kdy: 08. 04. 2010, 22:38:32 »
Pro praxi vypadá zajímavě http://www.seaside.st/ – pro tvorbu webů, jinak mi to přijde všechno moc akademické.
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.
63
Server / Re: Kompletní záloha celého serveru/VPS
« kdy: 05. 04. 2010, 23:35:30 »
To platí hlavně u Windows – které se se změnou HW nevyrovnají, nebo se jí dokonce záměrně brání. V Linuxu je přechod na jiné železo celkem v pohodě.
Většinou stačí ošetřit jen ty disky v /etc/fstab – pokud je tam jen jeden, stačí změnit UUID, pokud se na něj Grub odkazuje.
S architekturou problém být může – pokud by to bylo přechod z 64b na 32b (případně něco exotičtějšího jako ARM…) ale u serverů je dnes asi nejčastější 64b (resp. x86_64) :-)
Většinou stačí ošetřit jen ty disky v /etc/fstab – pokud je tam jen jeden, stačí změnit UUID, pokud se na něj Grub odkazuje.
S architekturou problém být může – pokud by to bylo přechod z 64b na 32b (případně něco exotičtějšího jako ARM…) ale u serverů je dnes asi nejčastější 64b (resp. x86_64) :-)
64
Server / Re: MySQL a primary indexy
« kdy: 05. 04. 2010, 17:45:08 »
1) rozlišovat klíče a indexy. Primární klíč souvisí s logikou věci – identita záznamu. Zatímco indexy jsou technická pomůcka pro zrychlení přístupu, k nalezení daného záznamu, řazení atd. Databázový systém sice typicky vytváří index při vytvoření PK, ale není dobré tyto pojmy slučovat. Indexů si můžu vytvořit kolik chci, bez ohledu na to, jaké mám nebo nemám PK – můžu si udělat třeba index nad jedním sloupečkem, který už je součástí složeného PK.
2) V tvém případě se jedná o normální vazební tabulku → složený primární klíč je zcela na místě, neboj se ho :-)
3) Cpát automaticky do každé tabulky umělé číselné ID jako primární klíč je s prominutím hloupost. Umělým PK je lépe se vyhýbat a používat je jen když je to nutné – když neexistuje nějaký přirozený identifikátor. Případně tehdy, pokud k tomu máme nějaké vážné důvody (např. výkonnostní). Ale to není tento případ. Je dobré se zamyslet, jestli budeme někdy potřebovat adresovat konkrétní řádek na základě toho umělého ID. Budeme? Povede odněkud odkaz na toto umělé ID? Nebo naopak povedou odkazy na ty složky složeného PK? I kdybychom tam totiž to umělé ID jako primární klíč „napchali“, bude nám na nic. Všechny JOINy se budou dělat přes jiné sloupečky. Nebo když např. budeme chtít nějaký záznam smazat, budeme vědět, že chceme smazat záznam, kde a=123 AND b=456, nikoli záznam kde id=234. Takový primární klíč je zbytečný.
Tohoto zlozvyku bych doporučoval se zbavit :-) Primární klíč nemusí být jen číslo a už vůbec nemusí být tvořen jen jedním sloupečkem. A jsou dokonce i tabulky, kde primární klíč nemusí být vůbec (byť je to celkem vzácné).
4) Tohle „idDoTbl1, idDoTbl2 vchnakejTextik“ měly být názvy sloupečků, nebo je to jen nějaký příklad? Trochu mi to připomíná maďarskou notaci ;-)
2) V tvém případě se jedná o normální vazební tabulku → složený primární klíč je zcela na místě, neboj se ho :-)
3) Cpát automaticky do každé tabulky umělé číselné ID jako primární klíč je s prominutím hloupost. Umělým PK je lépe se vyhýbat a používat je jen když je to nutné – když neexistuje nějaký přirozený identifikátor. Případně tehdy, pokud k tomu máme nějaké vážné důvody (např. výkonnostní). Ale to není tento případ. Je dobré se zamyslet, jestli budeme někdy potřebovat adresovat konkrétní řádek na základě toho umělého ID. Budeme? Povede odněkud odkaz na toto umělé ID? Nebo naopak povedou odkazy na ty složky složeného PK? I kdybychom tam totiž to umělé ID jako primární klíč „napchali“, bude nám na nic. Všechny JOINy se budou dělat přes jiné sloupečky. Nebo když např. budeme chtít nějaký záznam smazat, budeme vědět, že chceme smazat záznam, kde a=123 AND b=456, nikoli záznam kde id=234. Takový primární klíč je zbytečný.
Tohoto zlozvyku bych doporučoval se zbavit :-) Primární klíč nemusí být jen číslo a už vůbec nemusí být tvořen jen jedním sloupečkem. A jsou dokonce i tabulky, kde primární klíč nemusí být vůbec (byť je to celkem vzácné).
4) Tohle „idDoTbl1, idDoTbl2 vchnakejTextik“ měly být názvy sloupečků, nebo je to jen nějaký příklad? Trochu mi to připomíná maďarskou notaci ;-)
65
Server / Re: Zabezpečení SSH proti útokům hrubou silou
« kdy: 05. 04. 2010, 17:24:56 »
ad alfi: a taky už bylo mnohokrát vyvrácena smysluplnost tohoto „bezpečnostního“ opatření.
66
Server / Re: Kompletní záloha celého serveru/VPS
« kdy: 05. 04. 2010, 17:11:37 »
Případně rdiff-backup http://www.root.cz/clanky/zaloha-dat-pomoci-rdiff-backup/, který umí ukládat i starší verze a samozřejmě zálohuje přírůstkově. A nezapomeň ze zálohy vyloučit adresáře jako /dev /proc /tmp (asi i /log a možná další), které je zbytečné zálohovat.
67
Odkladiště / Re: Dokumentární film - Otevřené formáty dokumentů a OpenOffice
« kdy: 03. 04. 2010, 21:43:53 »
BTW: nepleteš tam XML a XSL? Nebo jsem jen špatně slyšel?
68
Odkladiště / Re: Dokumentární film - Otevřené formáty dokumentů a OpenOffice
« kdy: 03. 04. 2010, 21:39:05 »
Ahoj. Jakou má to video licenci? Je možné ho stáhnout a kopírovat dál? (nebo jen šířit odkaz na YT).
69
Software / Re: Bankovní linux
« kdy: 28. 03. 2010, 13:17:38 »
Použít můžeš prakticky jakoukoli – bezpečnější to bude už tím, že je to Linux :-)
Pokud to budeš používat tak, že vždycky nabootuješ to LiveCD a v něm budeš chodit pouze pro přístup na stránky banky a nikam jinam, tak se nemáš čeho bát. Bude to hodně bezpečné – v podstatě na stejné úrovni, jako kdybys měl vyhrazený počítač pouze pro přístup do banky.
Pokud to chceš používat i na normální prohlížení webu (tzn. nějakých i potenciálně závadných stránek, které by mohly zneužít zranitelností prohlížeče), doporučuji si v Linuxu vytvořit dva uživatele a jejich domácím adresářům nastavit taková práva, aby jeden nemohl do druhého*. Pak toho jednoho uživatele budeš používat pouze pro přístup do banky a i kdybys pod druhým uživatelem měl děravý prohlížeč a nějaká stránka by toho zneužila, neovlivnila by toho druhého uživatele, který slouží pro přístup do banky.
Případně se dají omezit práva prohlížeče ještě pomoci AppArmor, ale oddělení těch uživatelů je základ.
*) chmod 700 /home/*
Pokud to budeš používat tak, že vždycky nabootuješ to LiveCD a v něm budeš chodit pouze pro přístup na stránky banky a nikam jinam, tak se nemáš čeho bát. Bude to hodně bezpečné – v podstatě na stejné úrovni, jako kdybys měl vyhrazený počítač pouze pro přístup do banky.
Pokud to chceš používat i na normální prohlížení webu (tzn. nějakých i potenciálně závadných stránek, které by mohly zneužít zranitelností prohlížeče), doporučuji si v Linuxu vytvořit dva uživatele a jejich domácím adresářům nastavit taková práva, aby jeden nemohl do druhého*. Pak toho jednoho uživatele budeš používat pouze pro přístup do banky a i kdybys pod druhým uživatelem měl děravý prohlížeč a nějaká stránka by toho zneužila, neovlivnila by toho druhého uživatele, který slouží pro přístup do banky.
Případně se dají omezit práva prohlížeče ještě pomoci AppArmor, ale oddělení těch uživatelů je základ.
*) chmod 700 /home/*
