Nabídka

Zobrazit příspěvky

Zde lze prohlédnout všech příspěvky uživatele. Jsou zde vidět pouze příspěvky z oblastí, do kterých máte přístup.

Nabídka Zobrazit příspěvky

Příspěvky - Palo M.

#31
IMHO v UEFI staci vypnut secureboot. Vsetky 2 stroje s UEFI 8), ktore som mal doteraz v rukach, to umoznovali (respektive som ich skladal z komponentov, takze to standardne bolo vypnute - na stroji s predinstalovanymi Windoze8 to bude naopak standardne zapnute). Ale vsade sa to vypina inym sposobom (ma to vselijake krypticke nazvy v menu), takze to zavisi od typu (vyrobcu) dosky.
#32
Hardware / Re:Disk 1 TB
06. 03. 2014, 06:04:41
Aha, tak to neviem, ci Windoze 7 podporuju GPT, nikdy som to neskusal (a v povodnej otazke sa dualboot nespominal). Asi by sa to dalo obist pouzitim hybridnej MBR+GPT, ale to sa pre zaciatocnika velmi nehodi. Takze ak mas disk do 2TB a dualboot s Windoze, asi bude bezpecnejsie pouzit MBR. Ale to zarovnanie oddielov na 4K rozhodne odporucam, inak vyrazne klesa vykon disku (tiez neviem, ako deli disk instalator Windoze 7, to by snad mohol doplnit niekto kto s tym pracoval a skumal to).
#33
Hardware / Re:Disk 1 TB
05. 03. 2014, 04:21:55
Nad 2 TiB musi byt pouzite rozdelenie disku pomocou GPT, nie MBR. (Pre istotu dodatok kvoli chaosu s jednotkami: Disky, ktore sa predavaju ako 1TB ci 2TB su mensie nez 2TiB, takze tam sa da pouzit aj MBR aj GPT, ale disky od 3 TB vyssie uz potrebuju GPT.)
Vo Wheezym GPT funguje bez problemov, ja pouzivam utilitu gdisk (funguje velmi podobne ako stary dobry fdisk). A GPT sa pouzije automaticky pri instalacii, ak nabootujes instalator v EFI rezime (EFI boot vyzaduje GPT).
Takisto, novsie disky maju 4096-bytove fyzicke sektory (starsie mali 512-bytove), takze pri novsich diskoch je velmi vhodne dat pozor na zarovnanie oddielov (gdisk robi zarovnanie automaticky).
#34
/dev/null / Re:Firewall
02. 01. 2014, 10:28:32
Takmer vsade. To je uloha do skoly? Vyzera to totiz tak - a v tom pripade sa to namiesto somrovania po forach poriadne douc...

EDIT: Tak mi to nedalo... a fakt, je to uloha do skoly:
http://forum.linux-mint-czech.cz/viewtopic.php?t=552&p=3428
http://www.abclinuxu.cz/poradna/linux/show/386229
::)
Sorry, ale to zadanie je jednoducha zalezitost a z tebou navrhnuteho riesenia je jasne, ze tomu vobec (ale vobec) nerozumies. V takomto pripade je uplne zbytocne ti pisat spravne riesenie ktore niekam opises, pretoze ak skusajuci nie je uplny trubiroh (alebo podobne lenivy ako ty), tak velmi rychlo zisti, ze tomu nerozumies... :P
#35
Suhlasim s Otom. Ten popisany postup by pravdepodobne skoncil katastrofou. V Ubuntu je napriklad upstart, ktory v Debiane vobec nie je, takze by pravdepodobne nenabehlo niekolko demonov a kym by si to rozchodil, preslo by rozhodne viac ako 20 minut (ak by si to vobec rozchodil). A tych rozdielov je tam pravdepodobne viac. S downgradom niektorych balikov by tiez mohol byt problem (napriklad mysqld?). A akonahle by sa nieco v prostriedku procesu pokazilo, pravdepodobne by si sa ani nemal ako vratit k predchadzajucemu chodivemu stavu...

Ak je na disku daneho servera volny oddiel s dostatocnym miestom (alebo sa da disk preorganizovat za chodu), bolo by mozne nainstalovat Debian do toho volneho oddielu (s ponechanim Ubuntu) a postupne nainstalovat a nakonfigurovat tie sluzby, co bezia na Ubuntu,podla toho ako sa stiha a ku koncu casoveho okna zase bootnut do Ubuntu a pokracovat dalsiu noc (predpokladam, ze tych 20 minut nie je jednorazovych, ale ze vzdy v noci moze byt server dole na menej nez 20 minut).
Ale tato moznost silne zavisi od toho, ako je rozdeleny disk, mozno to v sucasnom stave tymto postupom nebude mozne.

Dalsia moznost je, zobrat uplne cisty disk a off-site tam naistalovat Debian, vsetko si pripravit a nakonfigurovat. A potom v noci iba vypnut server, prehodit disky, nastartovat a skontrolovat, ci to frci. Ak nieco neklapne, hodit nazad povodny disk s Ubuntu a potom (znova off-site) vyriesit co nechodilo a skusit to nabuduce znova.
Tu zas potrebujes fyzicky pristup k serveru. (A jeden volny disk navyse, samozrejme.)
#36
Hardware / Re:Blackscreen po upgradu - nVidia
20. 12. 2013, 06:20:42
Citace od: RayeR kdy 19. 12. 2013, 19:21:37OK, na to se budu muset podivat, jaik ses tim DKMS naraba, jesi mas po ruce link na nejaky tutorial...
Predpokladam, ze DKMS uz mas nainstalovane (kvoli tym VirtualBox modulom), takze si pozri:
more /usr/share/doc/dkms/HOWTO.Debian
more /usr/share/doc/dkms/examples/sample.conf
man dkms

V podstate ide len o rozbalenie zdrojaku toho konkretneho modulu do /usr/src/<menomodulu>-<verziamodulu>, vytvorenie spravneho dkms.conf a potom uz len frcis s jednotlivymi prikazmi podla HOWTO.Debian. Ten dkms.conf vacsinou staci pomerne jednoduchy, mozes sa inspirovat aj tuto: https://wiki.kubuntu.org/Kernel/Dev/DKMSPackaging a samozrejme si mozes aj pozriet, ako je to urobene v tych virtualboxovych DKMS moduloch (tam je myslim z jedneho zdrojoveho adresara generovanych niekolko modulov jadra, takze je to uz trocha komplexnejsi priklad). A tiez sa cely proces kompilovania da absolvovat vo virtualnej buildovacej masine, nakoniec vyrobit balik cez dkms mkdeb a na desktope potom staci len nainstalovat ten dany balik.

Citace od: RayeR kdy 19. 12. 2013, 19:21:37Aha, to taky neznam, muzes k tomu  LD_PRELOAD neco bliz? Slo mi o uz hotove binarky, kdyz byla kompilace prilis komplikovana nebo nebyl src a byla tam ta zavislost na novejsich libc. Pod woknama se to snadno vyresi nakopirovanim DLL do adresare k EXE a on primarne hleda knihovnu tam a az pak v systemu, takze tohle je nejaka obdoba?
Suchu teoriu o dynamickom linkovani najdes v:
man ld.so
Premennu LD_LIBRARY_PATH asi poznas, ta sa pouziva ak potrebujes pridat cestu k nejakym dalsim dynamickym knizniciam (typicky specificke kniznice pre dany program, kde nema zmysel robit ich systemove, pretoze ich pouziva len tento program). Premenna LD_PRELOAD je nieco podobne, akurat ze sluzi na override (aj systemovych kniznic).
Hodim priklad, aby ta teoria mala zmysel: Mas dynamicky linkovanu binarku v /opt/app1/bin/app1 a cez ldd zistis, ze dynamicky linkuje (systemovu) /lib/libc.so.6, ale ldd zaroven zanadava, ze GLIBC_2.xx nebolo najdene (tj. systemova libc.so.6 je skompilovana so starsou verziou glibc). Pri pokuse o spustenie /opt/app1/bin/app1 ti to samozrejme zhuci. Takze urobis to, ze nakopirujes novsiu verziu libc.so.6 (pre jednoduchost povedzme ze ju manualne vypitves z novsieho balika z unstable/testing, v horsom pripade ju budes musiet sam skompilovat) do /opt/app1/lib/libc.so.6
No a urobis si jednoduchy wrapper /opt/app1/run:
#!/bin/sh
LD_PRELOAD=/opt/app1/lib/libc.so.6 /opt/app1/bin/app1

A ked spustis /opt/app1/run, tak uz to frci (pouzije sa /opt/app1/lib/libc.so.6 namiesto systemovej /lib/libc.so.6).
A ldd tiez berie LD_PRELOAD do uvahy, takze:
LD_PRELOAD=/opt/app1/lib/libc.so.6 ldd /opt/app1/bin/app1
ti ukaze, ze sa bude pouzivat prave ta specialna verzia (a uz nenadava, ze GLIBC_2.xx nebolo najdene, pretoze v tej specialnej verzii dane glibc je)

Citace od: RayeR kdy 19. 12. 2013, 19:21:37Jo to ma neco do sebe. Vlastni baliky programu zatim delat neumim, jak rikas s make uninstall bejva problem. Moje vlastni programky sou zatim jednoducha binarka - 1 soubor, takze tam nakou instalaci neresim, ale u dalsich programu, kde sou i nake knihovny a vic souboru by se to hodilo udelat distribucni deb.
Vhodny priklad na vyuzitie checkinstall je tu: http://josesantiagojr.com/post/41299188705/install-ffmpeg-on-ubuntu-from-source
Pre vlastnu potrebu je to vacsinou postacujuci sposob na vytvorenie balika (nie je to vhodne na zlozitejsie baliky, ak vyzadujes zavislosti na inych balikoch, patche voci upstreamu a podobne).
#37
Herní­ zóna / Re:SteamOS
19. 12. 2013, 06:00:10
Tak ja som nikde necital ziadne oficialne vyhlasenie, ze to bude urcite rovno bootovat do BigPicture screenu, takze iste to nie je.
Ale logicky mi to vyplyva z krokov Valve, ze sa snazia o vlastnu distribuciu (inak by to snad vybavili tym, ze povedia "nainstalujte si Ubuntu, to oficialne podporujeme" a este by bol aj Canonical vysoko poteseny). Podla mna cielom Valve je naozaj vyvinut system pre konzoly typu "zapnem a hram", ale zaroven im vobec nevadi, ak Steam klient pojde navyse aj na inych platformach (kompy s Windoze, OS X, Linux). Klon inej distribucie by nemal ziadnu pridanu hodnotu, start do BigPicture tu pridanu hodnotu (pre stroje urcene primarne na hranie) ma...

No ale je to len moja uvaha, takze zatial agentura JPP 8)
#38
Hardware / Re:Blackscreen po upgradu - nVidia
19. 12. 2013, 05:51:10
Tak pises, ze potrebujes verziu jadra minimalne 3.7.1. A ja som uz predtym napisal, ze vo wheezy-backports je 3.11. Rovnako je 3.11 aj v testingu ci unstable. IMHO 3.11 > 3.7...

Ja som si cez DKMS musel pridat modul pre senzorovy chip, odvtedy som to nemusel updatovat vobec. Zmenene hlavicky jadra sa nedeju v ramci jednej verzie jadra (ak mas povedzme verziu 3.2 z distribucie a chodia k nej priebezne updaty, hlavicky sa nemenia nekompatibilnym sposobom, takze je to stale rovnako kompilovatelne). Az ked si povies, ze namiesto jadra 3.2 pouzijes jadro 3.10, tam uz mozu byt hlavicky ine (ale nemusi sa to tykat tvojho modulu), ale to sa ti neupdatne "samo", v takom pripade to robis manualne, mas na to cas a skontrolujes aj, ci DKMS zafunguje (a ak nie, tak ten modul doplnis o podporu noveho jadra).

Prave co sa tyka ovladaca grafiky a jadra, ist mimo distribucnych balikov moze neskor vyrobit zavislostne problemy, z ktorych sa tazko vysekava. To, ze v distribucnych balickoch nie je nejaky specialny program, ktory chces pouzivat, takze si ho musis sam skompilovat, vacsinou nie je vobec problem (pretoze od toho programu potom nezavisi plno inych veci).

S libc byva otrava, ale doteraz som nastastie nemal problem so zdrojakmi programov (isli skompilovat aj so starsou verziou libc), len s binarkami (dynamicky linkovali libc a ocakavali nejaku minimalnu verziu, novsiu nez ta co bola v systeme). Potom je este moznost hacknut to pomocou LD_PRELOAD a novsiu verziu libc mat nakopirovanu niekde mimo systemu s tym progamom (tato finta sa inak dost casto pouziva napriklad pri niektorych hrach - nie je to sice idealne mat aj inu verziu dynamickych kniznic oproti systemovej, ale zase je to funkcne riesenie, vo vacsine pripadov ta nedostatok pamate netrapi a hlavne to nerozbija cely system kvoli nejakemu jednemu specifickemu programu).

Neviem co presne za "specializovane programky" pouzivas, ci su sirene len ako binarky alebo aj ako zdrojaky. Ale v pripade vlastnej kompilacie som zistil, ze je velmi vhodne vyhnut sa "make install". Lepsie je dany program skompilovat vo virtualnej masine a tam pouzit checkinstall a takto vygenerovany balik potom nainstalovat na hlavnej desktopovej masine. Ak mam balik, viem ho kedykolvek odinstalovat (nie vsade sa autori zdrojakov "obtazuju" s "make uninstall", skor by som povedal, ze vacsinou uninstall target v makefile uplne chyba). A virtual je dobre pouzit z dvoch dovodov: 1. Ten checkinstall nemusi vzdy 100% zafungovat, ak su makefiles nie celkom korektne a robia nejake kopirovacie divociny, tak sa moze do systemu nakopirovat aj nieco, co nie je sucastou vysledneho balika a je to potom "neodinstalovatelne" a tazko sa to hlada. Oproti tomu pri instalacii vygenerovaneho balika system presne vie, co sa kde nakopirovalo a vie to v pripade potreby kompletne purgnut (mozni "neodinstalovatelni duchovia" ostanu vo virtuale a nezahnoja desktopovy stroj). 2. Na skompilovanie programu mozu byt potrebne rozne *-dev baliky, ktore na desktopovom stroji inak nemaju opodstatnenie, pripadne ani nie su v distribucii (alebo su distribucne baliky vyrobene s inymi volbami, napriklad curl, cares, wxwidgets, ...) a pre dany program treba najprv kompilovat/instalovat 3rd party kniznice. Skratka vo virtuale sa s tym da vyhrat a ked to nahodou neklapne, tak rozhaseny buildovaci virtual ti neprirobi tolko roboty, co rozhaseny hlavny desktop. A nie je to prakticky ziadna robota navyse, ak sa ti jednoduchy program normalne skompiluje, tak checkinstall tiez vzdy zafunguje.

Takze z tvojho popisu pouzitia mi Debian stale pripada ako vhodny (vlastne aj ja ho pouzivam podobne)... ovsem do jadra a ovladacov nerypem kym nemusim (a z tvojho popisu sa mi tiez zda, ze by si nemusel any ty a vyhol by si sa problemom typu $SUBJECT).
#39
Herní­ zóna / Re:SteamOS
18. 12. 2013, 06:57:33
Podla mna nestihali a chceli nieco vydat este tento rok, no tak nieco vypustili. Takze momentalne je to nedorobena prechodna verzia, take demo (pomerne funkcne, ale nie finalna podoba).
Dorobene by to snad malo bootovat rovno do Big Picture bez prihlasovania do systemu, len prihlasenie na Steam a hras... potom bude mat vyznam instalovat to na "obyvackovu" masinu na drtenie. Na normalnom kompe (ktory pouzivas aj na nieco ine ako na hranie) to asi velky vyznam nema...
#40
Hardware / Re:Blackscreen po upgradu - nVidia
18. 12. 2013, 06:51:55
1. Mas zvlastnu kombinaciu HW, ked potrebujes nove jadro kvoli (asi novemu) DVB-T tuneru a pritom mas starsiu grafiku... ale aj toto vyzera byt riesitelne s balikmi:
Vo wheezy-backports je metabalik nvidia-legacy-304xx-driver (pouzit namiesto metabaliku nvidia-glx) - mal by fungovat spolu s jadrom z wheezy-backports (s jadrom 3.11 alebo 3.10). Takze by si mal mat aj patricny nvidiacky driver na tvoju kartu a aj dostatocne novu verziu jadra.

2. Tvoje poznatky o balickoch s proprietarnymi ovladacmi (napriklad nvidia-glx) su uz zastarale. Moduly jadra sa uz nejaky cas nedistribuju binarne, ale ako zdrojaky pre DKMS. Takze v pripade, ze dojde k instalacii novsieho balika jadra, tak sa "sama" spusti kompilacia modulu jadra (s novymi hlavickami jadra) a takto skompilovany (uz binarny) modul jadra sa prida do patricneho adresara v /lib/modules/... ak nahodou kompilacia DKMS neprejde (napriklad ak sa zmenia hlavicky jadra v novsej verzii), tak to pri tom update zanadava a ty o tom vies (takze to bud vyriesis, alebo sa aspon vratis k predchadzajucej verzii - hlavne nemusis zapasit s fenomenmi typu "blackscreen po update"). Okrem toho, proprietarny "ovladac" pre grafiku nie je v Debiane len jeden balik. Jeden balik je pre samotny modul jadra, jeden je pre Xorg a este je niekolko dalsich balikov (pozri napriklad ake vsetky sa generuju z nvidia-legacy-304xx-driver). To, ze je to rozdelene do viacerych balikov ma svoj vyznam, pretoze od tych balikov zavisia zase nejake ine baliky... takze ked nenainstalujes baliky z distribucie, tak sa ti moze pri nejakom programe stat, ze mu bude chybat zavislost => baliky su v podstate rozbite, aj ked sa ta to momentalne mozno nedotyka a nevidis to a dokonca mozes tvrdit "funguje mi to vyborne".

3. S kompilovanim vlastneho jadra je extra robota. "Skompilovat vlastne jadro" pritom moze viest k viacerym vysledkom, podla toho, ako to urobis: Mozes napriklad zobrat zdrojak z kernel.org a ist cez menuconfig, make, make install - co je velmi zly napad. Mozes zobrat jadro z kernel.org a ist cez make-kpkg, vyrobit tak .deb balik a ten nainstalovat (to uz je omnoho lepsi napad). Ale ked si pozries zdrojovy balicek jadra v Debiane (je jedno v ktorej vetve), uvidis tam vzdy plno roznych patchov (oproti kernel.org jadru) na tu konkretnu verziu jadra - a tie by si tam nemal (znova, toto je kus roboty co za teba spravili ludia z distribucie!). Takze dalsia moznost je nainstalovat balik linux-source, ktory ma tie patche v sebe tiez a tiez je vysledkom .deb balik (samozrejme tato moznost pada, ak potrebujes taku specialnu verziu jadra, ktora v distribucii prave nie je - ale potom fakt musis ocakavat problemy s nekompatibilitou).
IMHO ma vlastna kompilacia jadra ale vyznam len v tom pripade, ak potrebujes zapnut nejake specialne volby v tom menuconfig-u, ktore v standardnych balikoch zapnute nie su (napriklad chces pouzit konkretny process scheduler, alebo chces osekat jadro pre konkretnu masinu kde mas malo pamate, vies co tam nepotrebujes a da sa na tom usetrit pamat, pripadne mas velmi dobry dovod na vyrobu velkeho monolitickeho jadra a vypnuti podpory dynamickych modulov) - skratka mas nejake naozaj specificke potreby a stoji ti za to sa s tym kaslat.
Ale z tvojho popisu mi vobec nepripada, ze by si vobec musel kompilovat vlastne jadro. Ty podla vsetkeho potrebujes len ten ovladac na DVB-T prijimac. S vysokou pravdepodobnostou je to jednoducho dosiahnutelne nasledovne:
a) Ovladac je v jednom z jadier vo wheezy-backports: Nainstalujem jadro, hotovo, nic ine netreba riesit.
b) Ovladac nie je v ziadnom z jadier, ale je s nejakym kompatibilny: stiahnem zdrojak ovladaca, vyrobim z neho DKMS balik (to uz nie je uplna trivialita, ale rozhodne je to lepsie nez kompilovat cele jadro), otestujem ze chodi, hotovo.
Skratka kvoli jednemu zariadeniu (DVB-T) sa neoplati prirobit si kopec roboty, rozbit si balicky jadra a potencialne prist o updaty jadra.

Vies, ide to urobit aj uplne prasacky a stale to bude akoze fungovat: Sam si skompilujes nejake jadro a len tak ho nejako svacnes do suboroveho systemu (make install, ci dokonca cp), skompilujes prasacky nvidiacky .run ktory rozkopiruje vselico hore-dole, dopises do grub.cfg staticku polozku s vlastnym jadrom aby ti to vobec bootlo a ked pouzijes vzajomne kompatibilne verzie, tak to nakoniec mozes dostat do chodiveho stavu a bude to asi aj celkom funkcne... v tom danom case... ak nenarazis na to, ze nejaky iny program ktory by si chcel bude potrebovat nejake zavislosti... Ale potom priebezne sleduj, ci nebola vydana opravna verzia jadra a opakuj to cele znova...

Ale v tom pripade vobec nemusis mat Debian, mozes si dat nejaky Linux From Scratch alebo nieco podobne. Vyhoda Debianu je prave v jeho balickovacom systeme, v bezpecnostnych updatoch a pri stable vetve aj v tom, ze jednotlive verzie balikov spolu funguju - a pre vela z nas su tie vyhody take vyrazne, ze nam nevadia mierne starsie verzie jednotlivych programov. Ale ked zacnes v systemovych zalezitostiach (akou jadro rozhodne je) obchadzat balickovaci system, tak tym stratis vyhody, ktore to prinasa, stratis stabilitu... a ostanu ti akurat tie starsie verzie programov. A pritom sa este aj narobis a budes zlozito robit nieco "po starom" aj ked dnes uz sa to da urobit omnoho jednoduchsie.

Mozno je to trocha frustrujuce, ze kedysi si sa naucil ako kompilovat jadro a instalovat ovladac a dnes uz ten postup nie je najlepsia cesta a treba sa zase nieco nove naucit... plus kopec navodov na webe je uz zastaralych a zbytocne ta dopletu... Ale podla mna sa prave veci suvisiace s jadrom vyvijaju celkom dobrym smerom.
#41
Hardware / Re:Blackscreen po upgradu - nVidia
17. 12. 2013, 06:15:48
A je nejaky dovod, preco si sa zufalo pokusal pouzit NVIDIA-Linux-x86-304.88.run (balik priamo od Nvidie)?

IMHO si mal nasledujuce moznosti:
1. Na Wheezy so standardnym jadrom 3.2 pouzit standardne baliky (nvidia-glx vo verzii 304.88 teda tej istej co si instaloval). Netreba ziadne spekulacie a malo by to chodit.
2. Ak si z nejakeho dovodu potreboval novsie jadro (napriklad ak mas novu dosku), vo wheezy-backports je jadro 3.10 a nvidia-glx vo verzii 319.72, teda novsej - opat by to spolu malo chodit.

Distribucne baliky driverov obsahuju totiz patche, ktore zarucuju, ze ta konkretna verzia drivera funguje s tym konkretnym distribucnym jadrom. Balik stiahnuty od Nvidie taketo patche neobsahuje, takze je vzdy kompilovatelny len s istou podmnozinou verzii jadra v danom case - s novsimi alebo starsimi sa skratka skompilovat neda, pretoze hlavicky jadra sa skratka menia, ako sa jadro postupne vyvija.

Distribucia tymi patchami spravila za teba kopec roboty (a byvaju tam aj ine patche, nielen take co su nutne aby sa ti vobec skompiloval modul v DKMS, ale aj rozne ine bugy), plus bude vydavat pripadne updaty - a ty si tu ich robotu vobec nevyuzil, kaslal si sa s nejakymi zabugovanymi verziami od Nvidie, zabil si kopec casu a nakoniec si to "poriesil" prechodom na testing, dalsou kompilaciou (a trojhodinovym spankom)... :P A to este nie je z tvojho postu jasne, ako si to vlastne "kompiloval", ci si vobec vyrobil .deb balik, alebo si len spustil ten nvidiacky .run, ktory sa s nejakym balickovanim vobec neobtazoval a rovno nakopiroval binarky "niekam" do /usr - a pri nejakom dalsom update v buducnosti ta mozno opat privita cierna obrazovka a zase budes musiet riesit (teda neviem, ci to este ta instalacka od Nvidie robi, kedysi to robila a vzdy to riadne rozbilo system, takze nasledny pokus o instalaciu normalnych balikov z distribucie zlyhal, museli sa najprv najst a manualne pomazat vsetky tie humusy, co tam nvidiacky instalator kde-kade porozhadzoval, az potom sa mohli nainstalovat normalne baliky).

Inak to s tymi drivermi plati rovnako aj pre AMD - kompilovat surovy driver od AMD je kopec roboty a pritom fglrx-driver v distribucii je plne funkcny, takze vacsinou netreba vobec spekulovat.

Jedine odovodnenie vo vlastnej kompilacii driverov vidim v pripade, ze potrebujes velmi novu verziu ovladaca, pretoze mas cerstvo zakupenu grafiku a ta starsia verzia ovladaca v distribucii s novym hardverom robi problemy. Vtedy za to ten kopec roboty s vlastnou kompilaciou stoji. Ale to zjavne nie je tvoj pripad, pouzil si starsiu verziu ovladaca, ktora je normalne vo Wheezy...
#42
gksudo ma ale tiez svoj vyznam: ked chces vytvorit novu polozku v menu a potom spustat danu vec z menu, bez terminalu. Povedzme take manualne nainstalovane IDE eclipse (rozbalene v /opt pod uzivatelom root), ktore bezne spustas ako normalny uzivatel (mas na to polozku v menu), ale raz za cas chces urobit updaty eclipse (na to mas druhu polozku v menu).

BTW: Ja ked uz mam otvoreny terminal a v nom roota, tak na editovanie suborov nepouzivam gedit, ale vim 8)
#43
Zalohovanie je pomerne komplexna zalezitost, jednoducha odpoved na otazku "co odporucate" teda neexistuje.

Napriklad, pri pouziti dd sa vytvori jeden klon daneho disku v danom case. Ak chcem aj nejaku historiu zaloh, povedzme poslednych 7 dni, tak potrebujem priblizne 7-nasobne viac miesta. To uz zacina byt dost neefektivne...
Inak co sa tyka toho SSD: Ak je zapnuty TRIM (co je pri SSD vysoko odporucane), tak sa bloky oznacene filesystemom ako volne (po zmazani suboru) oznamia disku a ten sa odvtedy tvari, ze tieto bloky su prazdne (akoby tam boli nuly), teda obraz takehoto disku je komprimovatelny vysokym kompresnym pomerom. Pri klasickom disku ale zostava obsah blokov po zmazani suboru na disku (len sa bloky oznacia ako volne - potom je mozne aj "undelete", ak tie "volne" bloky este neboli znovupouzite pre ine subory), takze po zaplneni klasickeho disku povedzme videom a jeho naslednym zmazanim sa komprimovatelnost obrazu disku pravdepodobne vyrazne zhorsi.

Ja napriklad spravidla nezalohujem cely system. Najdolezitejsi pre system je /etc (v kombinacii s balickom etckeeper, ktory automaticky priebezne uklada historiu zmien v /etc do verzovacieho systemu) a /var/backup (tam su jednak zalohy z dpkg-selections a tiez sluzieb ako mysqld alebo slapd - tiez je tam nielen posledny snapshot, ale aj niekolko predchadzajucich). Toto staci rsyncnut na iny stroj a s tymto by som v pripade dokazal obnovit cely system s potrebnymi sluzbami - zalohu veci ako /usr fakt nepotrebujem. Je pravda, ze v pripade uplneho krachu disku by som sa trocha viac narobil s obnovou systemu, pretoze by som ho musel znova instalovat, aj vsetky dalsie baliky podla dpkg-selections a potom este prekontrolovat konfiguraciu, ale zase na serveri mam RAID1, takze totalny vypadok nie je az taky pravdepodobny (a este sa mi to nestalo). Pre mna je dolezitejsie, ze nezalohujem veci, ktore su nahraditelne, ale len konfiguraciu (lebo v tej je kus mojej roboty). Ale kazdy moze byt v inej situacii. Preto univerzalne odporucanie neexistuje.

Na zalohu nesystemovych dat (napriklad uzivatelske adresare) pouzivam momentalne rdiff-backup (predtym tiez rsync, ale to bol tiez len jediny snapshot momentalneho stavu bez historie, pri rdiff-backup sa da uchovavat historia zmien podla potreby). Uchovava to momentalny snapshot a "reverzne inkrementy", teda starsia verzia je vzdy diff k novsej verzii - daju sa potom lahko zmazat "prilis stare" verzie bez toho, aby sa manipulovalo s tymi cerstvejsimi. Tiez to pouziva hardlinky a ine finticky, takze celkova velkost zalohy je celkom znesitelna. Navod na rdiff-backup je napriklad tu.

Prave sa trocha pohravam s myslienkou, ze si vyskusam zalohovaci system Bacula, vyzera zaujimavo. Paci sa mi na tom, ze sa da komplexne vyriesit zalohovanie viacerych strojov (pri tom rdiff-backup je to skor o tom, ze na kazdom stroji je to nakonfigurovane trocha inak podla potreby a pri viacerych strojoch zacina byt trocha gulas v tom, co sa odkial kam zalohuje). Ale konfiguracia je zlozitejsia...
#44
No a v tvojom sposobe pouzitia je prave chyba.
gksudo funguje tak, ze ako prihlaseny pouzivatel (ten, pod ktorym bezi graficke prostredie a ma pravo spustat graficke aplikacie) spustis gksudo, to si vypyta heslo (v pripade gksudo je to heslo pouzivatela, nie heslo roota) a potom sa dana graficka aplikacia spusti sice pod danym prihlasenym uzivatelom (teda ma pravo vytvorit graficke okno a zobrazovat na X-server), ale zaroven s pravami roota (teda ma napriklad pravo zapisovat subory, ktore su pre prihlaseneho uzivatela len na citanie).

Ale opakujem, aby gksudo fungovalo, tak samotne sudo musi byt spravne nakonfigurovane. Na webe je plno navodov k sudo, tak si ich radsej precitaj, aby si si sam vedel overit, ci mas sudo nakonfigurovane spravne (a pripadne si ho nastavit podla potreby).
#45
GPT je stale pomerne nova zalezitost, takze by som sa pre istotu nespoliehal na to, ze vsetky nastroje budu stopercentne fungovat.
Ak ma ale disk viac nez 2 TiB, tak uz GPT treba pouzit, pomocou MBR sa neda adresovat viac nez tie 2 TiB...

Co sa tyka velkosti sektora, pokial viem, tak sa vsetky disky tvaria, ze maju 512 B sektory. Tych 4096 B pri novsich diskoch je velkost "nativneho" sektora, s ktorym pracuje firmware disku interne (ak sa cita/zapisuje lubovolny 512-bytovy "logicky" sektor, disk musi precitat/zapisat cely 4096-bytovy "nativny" sektor na ktorom ten 512-bytovy logicky sektor lezi - a s nim aj dalsich 7 logickych sektorov) - prave preto je pri tychto diskoch dolezite zarovnat (tie 512-bytove) sektory na nasobok 8, inak brutalne klesa vykon disku - suborovy system, napriklad ext2/3/4, pracuje totiz tiez s 4096-bytovymi blokmi. Je dost hlupe, ze sa to prepocitava hore-dole a bolo by urcite lepsie, keby sa s novymi diskami pracovalo priamo s 4096-bytovymi sektormi bez prepocitavania (a samozrejme aj bez CHS, ktore dnes uz nemaju ziadne opodstatnenie), ale... spatna kompatibilita (Windoze by taky disk urcite nedali a nie som si isty, ci by s tym neboli problemy aj v linuxe - ved vsetky layouty - aj ten GPT - pocitaju s 512-bytovymi blokmi).
Z hladiska zalohy/kopie teda pravdepodobne netreba riesit problem 512/4096, malo by to fungovat aj ak sektory nebudu zarovnane, akurat to bude patricne pomalsie...

V kazdom pripade, podla mna dump celeho disku pomocu dd nie je velmi vhodny na pravidelne zalohovanie. Hodi sa to skor na nejake "jednorazove" laborovanie (napriklad ak boli omylom prepisane nejake sektory na disku a chcem z neho stale dostat data, tak cez dd urobim kopiu disku a hram sa s tou kopiou kolko chcem, na povodny disk nic nezapisujem, aby som tam nepokazil dalsie veci).