Příspěvky

IMHO sa fglrx-driver nechyti, pretoze ta karta vyzera byt prilis stara (je to Mobility Radeon, nie Radeon HDxxxxM). A kedysi to bolo s grafikami pre notebooky tak, ze na strankach ATI/Nvidia sa nedali pre ne vobec stiahnut ovladace, ale clovek musel ist na stranky vyrobcu notebooku (Asus, Sony, Toshiba, ...) - a v tych casoch vyrobcovia podporovali Linux vieme ako... takze je mala sanca, ze na nejakych strankach Lenovo vobec najdes nejaky proprietarny linuxovy driver - a ked aj najdes, tak zas nebude pasovat k novemu jadru, pretoze ho nabeton nikto neupdatoval.

Najlepsie asi bude skusit ten opensource radeon (pozor, nie radeonhd - to bol velmi nepodareny pokus o opensource ovladac na nove Radeony HD).
Ten radeon by snad mohol frcat, ale mozno budes potrebovat rucne nastavit xorg.conf. Pozri sem: http://www.thinkwiki.org/wiki/ATI_Mobility_Radeon_7500. A vlastne mozes pozriet aj cely notasek, keby si potreboval spojazdnit aj nieco ine: http://www.thinkwiki.org/wiki/Category:T42
Celkovo IBM notasky slapu s Linuxom pomerne slusne, takze mas celkom velke sance.

Linux standardne pocita s tym, ze systemove hodiny (tj. to, co vidis v BIOSe) je v UTC. Stredoeuropsky letny cas (to co vidis na svojich hodinkach) je o 2 hodiny posunuty voci UTC (inak napisane UTC+2). Ma to velku vyhodu - cas v BIOSe nastavis len raz a potom sa ho uz nechytas, zmeny casu letny/zimny, pripadne zmena casoveho pasma, sa deju len v OS.

Ak mas Debian ako jediny OS na stroji, najjednoduchsie je nastavit si v BIOSe UTC (teda o 2 hodiny menej, nez je cas na hodinkach v lete).

Ak mas dualboot s Windoze, tak treba trochu pobastlit, Windoze totiz naopak predpokladaju, ze cas v BIOSe je lokalny cas a spatne dopocitavaju UTC (a menia BIOSovsky cas pri zmene casu letny/zimny). V takom pripade musis:
a) Presvedcit Debian, ze hardverove (BIOS) hodiny nie su v UTC, ale v lokalnom case
b) Presvedcit Windoze, ze hardverove hodiny su v UTC.

Ak sa vydas cestou a), tak zedituj /etc/default/rcS na:

Kód [Vybrat] Rozbalit

UTC=no

Ak sa vydas cestou b), tak kedysi na XPckach to bolo:

Kód [Vybrat] Rozbalit

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
"RealTimeIsUniversal"=dword:00000001
(novsie Windoze neviem)

BTW: Applovsky OS X tiez pocita s tym, ze hardverovy cas je v UTC. Takze ti, co maju na Mac-och OS X v dualnom boote spolu s Windoze musia riesit tento isty problem... IMHO je lepsie aplikovat moznost b)

Vraj kedysi, este v predinternetovych dobach existovala nejaka "prirucka pre teroristov", kde boli vselijake navody pre takto zameranych ludi. A jeden z tych navodov bol na to, ako terorista zisti, ze mu kontroluju postu: Napise list sam sebe menom svojho fiktivneho priatela, kde spomenie "v liste ti prikladam aj blchu, ved vies preco". Ale ziadnu blchu tam nevlozi. Ked mu list potom pride a je v nom blcha, tak je jasne, ze mu kontroluju postu 8).

Takze kto chce fakt velmi-velmi zistit, ci mu trojpismenkove agentury kontroluju e-maily, moze skusit nieco podobneho stylu (samozrejme s fyzickou blchou to nepojde, musi si vymysliet nejaku virtualnu alternativu) ;D ;D ;D

Zdravim, som uplny amater a nechtiac som dal formatovat disk, su nejake moznosti obnovy dat?

Ano. Najlepsie je obnovit data zo zalohy.

Ze nemas zalohu? Tak v tom pripade pripojim jeden bradaty vtip: "Ludia sa delia na dve skupiny: Na tych, co pravidelne zalohuju a na tych, ktori este neprisli o dolezite data."



Ked si uz uplne zufaly, zalohu naozaj nemas a chcel by si aspon nieco vydolovat, tak skus PhotoRec. Podstatne ale je, aby si nic na dany preformatovany disk uz nezapisoval, pretoze s kazdym zapisom sa dalej znizuje sanca, ze odtial nejake data dostanes...

Ak to spravne interpretujem, tak o 18:30:39 bol posledny normalny zapis do syslogu a o 18:35:27 masina "zrazu" nabootovala - teda system zdochol len tak bez hocijakej zmienky o chybe do syslogu. Tak to moze byt vela veci. Od chyby v kerneli, cez dokurbabrany BIOS, az po (nechcem strasit) hardverovu chybu.

Skus zistit, ci to je urcite tym novym kernelom. Nainstaluj predchadzajucu verziu a uvidis, ci to stale robi. Verziu predchadzajuceho balika najdes v logu apt a balik samotny by mal byt na snapshot.debian.org...

[sarcasm]A my, co pouzivame stable, si vysoko vazime tvoju pracu na testingu.[/sarcasm]

Za narastom Tor "uzivatelov" je podla poslednych sprav botnet.

Co sa tyka "naburania" sifrovania tajnymi sluzbami, hovori sa aj o backdooroch umyselne nasadenych do sifrovacich programov. Ja osobne mam ale podozrenie na FUD (pokial ide o open-source programy, samozrejme) - IMHO je brutalne narocne zakomponovat backdoor do zdrojaku tak, aby nan nikto neprisiel.
Ci su backdoory tajnych sluzieb v komercnych closed-source produktoch (ala Windoze) to uz neviem, ale je mi to jedno, pretoze na to existuje velmi jednoduche riesenie - nepouzivat. Ale ked sa boja toho, ze by vacsina ludi zacala celu svoju komunikaciu sifrovat a oni by s tym potom nevedeli urobit VOBEC NIC, tak rozsirit FUD "ludia nesifrujte, je to zbytocna praca navyse a aj tak vam to tajne sluzby precitaju" je jedine, co s tym teraz mozu robit...

Prihlasovacia obrazovka zavisi od toho, aky mas login manager.
Ak pouzivas KDE, tak si mozes pozriet temy KDM napriklad tu: http://kde-look.org/, ak pouzivas Gnome, tak pravdepodobne GDM temy tu: http://gnome-look.org/. Pripadne mozes mat iny login manager, napriklad LightDM. Najjednoduchsie je najst nejaku funkcnu temu, ktoru uz niekto vyrobil a len si ju stiahnut. Mozes si samozrejme vyrobit aj svoju vlastnu, ale nebude to praca na 5 minut, hlavne ak si to este nikdy nerobil.

Screensaver s hodinami snad nejaky uz existuje (ja pouzivam len blank screen)...

A mame to tu. Pred casom sa objavil oznam, ze Debian-security team uz bude podporovat len ESR verzie Mozilly. Uz vtedy som sa obaval, co bude s rozsireniami (distribuovanymi ako debianovske baliky, teda xul-ext-*).

A dneska na mna vybaflo, ze je update icedove z 10.0.12 na 17.0.7, s nim aj enigmail... bohuzial s hlaskou "packages have been kept back". Tak som zistil, ze upgrade tychto balikov by odinstaloval xul-ext-adblock-plus (a ten by so sebou zobral aj xul-ext-adblock-plus-element-hiding-helper a aj gnome, ktore na nom zavisia). Takze predpokladam, ze v dalsom kole by to na mna asi vybaflo asi tak 124 balikov (vsetky, ktore metabalik gnome instaluje ako svoje zavislosti a nevyzaduje ich ziaden iny balik co som instaloval) ako pravdepodobne nepotrebnych... Patral som po pricinach a v dpkg --status xul-ext-adblock-plus na mna svieti "Breaks: ... icedove (>> 16.0~a1+)...". No parada!
Kym odinstalacia samotneho xul-ext-adblock-plus nie je az taky problem - akurat si to rozsirenie uzivatel musi nainstalovat sam v iceweasel, ale aj tak pouzivam zopar inych rozsireni, ktore nie su dostupne ako debianovske baliky... ale odinstalovanie metabalika gnome je fakt otrava.

Tak toto podla mna security team nezvladol. Keby napriklad vydali aj novsiu verziu xul-ext-adblock-plus (ktora nerozbija icedove 17), tak by vsetko prefrcalo hladko (ked ten adblock plus bezi s iceweasel 17, snad by nebol problem spojazdnit ho s icedove 17). Alebo keby aspon vydali novsiu verziu metabalika gnome (aby nezavisel od xul-ext-adblock-plus), tak ten adblock plus by som si do iceweasel uz doinstaloval (v icedove ho ani nepotrebujem)... a to nechcem vidiet, keby niekto mal ine desktopove prostredie, pouzival icedove a chcel by si "len" doinstalovat gnome - pravdepodobne mu to ponukne "skvelu" moznost odinstalovat icedove... Su to fetosi.

Kód [Vybrat] Rozbalit

root@debian:~# service mysql restart
[ ok ] Stopping MySQL database server: mysqld.
[FAIL] /etc/init.d/mysql: ERROR: The partition with /var/lib/mysql is too full! ... failed!
root@debian:~#

Zaujimavé ... preplnilo to :D

Podla tej hlasky sa ani nenastartuje mysqld, pretoze /var je plny (mozno ani nie je v samostatnom oddieli, v tom pripade je cely root file system plny. Ak ten Streamer's Admin potrebuje okrem PHP aj MySQL, tak to je s najvacsou pravdepodobnostou hlavny zdroj problemov.
Pouzi utilitky df a du, zisti, co ti zozralo miesto, vycisti disk a pripadne preorganizuj disk tak, aby to nabuduce nenastalo.
A mozno budu MySQL tabulky poskodene, napriklad ak doslo miesto uprostred nejakeho zapisu do databazy.

Debian podporuje oldstable vzdy priblizne rok po vydani noveho stable. Teda Squeeze bude dostavat updaty priblizne asi rok. Davat si teraz Squeeze nie je dobry napad, teraz je cas kedy treba preklapat existujuceho Squeeza na Wheezyho.
To casovanie nie je len taky vrtoch, ale ma to svoj zmysel: "nekonecne" udrziavanie vetvy oldstable by neunosne zatazovalo vyvojarov a o to viac by sa odkladalo nove vydanie.
V pripade CentOSu je ina situacia - je to v podstate len prekompilovany a debrandovany RedHat Enterprise - pre RedHat ma udrziavanie aj starych verzii jednoduchy pragmaticky vyznam: dostava za to zaplatene od firiem-pouzivatelov cez support (tie firmy to vacsinou pouzivaju na rozne svoje riesenia, prilis caste updaty by zase neumerne zatazovali tu firmu)... Takze CentOS sa skratka len vezie popri RedHat-e a len prebalickuje to, co RedHat vyda.

Wheezy+Mate je jednoznacne lepsia kombinacia nez zotrvavat na Squeeze+Gnome2 (nez cokolvek+Gnome2). Ale Mate ma pokial viem problem s tym, ze niektore aplikacie su uz postavene na GTK3 a tie vraj vyzeraju v Mate hnusne (lebo GTK2 styl prostredia sa na ne neaplikuje). Ten isty problem ma samozrejme aj Gnome2. Ak toto v Mate nejako urychlene nevyriesia, tak sa budu problemy len zhorsovat - rozne aplikacie budu prechadzat na GTK3, pripadne budu vznikat nove. Dlhodobe zotrvavanie na Mate bude potom coraz vacsie utrpenie, a samozrejme zotrvavanie na Gnome2 uplne este horsie... takze nechapem nazory typu "Gnome2 je najlepsie prostredie vsetkych cias a uz nikdy nechcem ine". Podla tejto logiky by sme jazdili stale na Skode Octavia (tej povodnej, z rokov 1959-1971), ta bola podla mnohych tiez lepsie auto nez nasledujuca 1000MB...

A este jednen faktor, ktory v mojom pripade zaposobil uz viackrat: Ziaden hardver nevydrzi vecne. Ked odide starsia doska, tak sa vacsinou viac oplati kupit cele nove creva, nez to nejako opravovat (nove dosky s identickym socketom/pamatami uz skratka nie su a davat tam nejaky sekacovy kus znamena koledovat si o to, ze po kratkom case to prdne znovu, plus stary HW zerie viac elektriny, ktora je coraz drahsia, takze aj keby bol ten stary HW zadarmo, tak sa to predrazi inak). Takze aj keby sa na jednoduche cinnosti (tj. nie server, len desktop na par jednoduchych cinnosti) teoreticky dalo pokracovat aj so starym a neupdatovanym systemom, tak v pripade vymeny HW uz zastaraly system zrazu nechodi (stare 2.6-kove jadra nepodporuju novsi hardver, takze napriklad nejde zvukovka a to uz nehovorim o vykonnejsich grafikach, a prasknut do stareho systemu nove 3-kove jadro zas vyrobi ine problemy), takze clovek je aj tak donuteny prejst na novsi system (ovsem v tomto pripade uz si nemoze velmi planovat kedy - ked je v dosledku padu HW bez kompu, musi to urobit urychlene).

Takze za mna jednoznacne: Up-to-date system, ziadne stariny. A nebat sa novych prostredi (ved clovek nemusi mat nainstalovane len jedine desktopove prostredie).

Odporucam precitat si release notes (lepsie je si ich precitat vzdy PRED upgradom). Konkretne tuto by mohli mat nieco pre teba: http://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#boot-timing (ak ta hlaska sedi a je to boot timing).

Este mozes mat zle devices.map (chyba v nich md0 z ktoreho chces bootovat, alebo ti tam naopak chyba sda1) alebo mas nedobre nainstalovany Grub (zavadzac sa nenainstaloval na ten disk, z ktoreho ides bootovat, ale na nejaky iny), pripadne sa ti nezavedu spravne grub2 moduly na pracu s RAID (update-grub by ale mal zabezpecit naladovanie spravnych modulov)...

Inak ako UUID v nastaveni grubu by som radsej pouzil md0 (ak mas teda root na md0) a nie sda1... Z sda1 (a k tomu analogicky pridane sdb1 pre pripad, ze prvy disk je zly) sa bootovalo v grub1 (ktory nevedel robit s RAID zariadeniami).

Ak mas zdrojak, tak vidim 2 varianty:
1. Najdes si zdrojaky tych kniznic "navyse" (tych co nie su v stable repozitari, tj. libqextserialport1) a skompilujes si najprv tie, az potom kompilujes vlastnu aplikaciu.
2. Nainstalujes si tie "navyse" kniznice z experimental vetvy (inde zjavne nie su).

Vyhoda prvej varianty: Mas pod kontrolou prakticky celu aplikaciu, aktualizacie 3rd party kniznice libqextserialport1 ti nerozbiju tvoju aplikaciu (pouzivas stale tu istu verziu kniznice z urciteho datumu, ktoru mas odskusanu a funkcnu). A tiez to ide pomerne jednoducho prekompilovat na lubovolnom dalsom systeme (nie nutne na Debiane), pretoze z kniznic potrebujes iba tie bezne, ktore su dostupne prakticky vsade.
Trocha nevyhoda zase je, ze mozu byt problemy so skompilovanim tej kniznice (len v experimentale asi nebude len tak zo srandy, tiez na jej skompilovanie mozes potrebovat kopec dalsich zavislosti ktore nie su potrebne na beh samotny, len na tu kompilaciu) a takisto ak pride nejaky update k tomu libqextserialport1, ktory sa ti celkom hodi do tej aplikacie, musis to cele znova prekompilovat aby si ten update mohol zacat pouzivat.

No a vyhoda druhej varianty je zasa v tom, ze mas o jednu vec menej na kompilovanie, skratka len priinstalujes balik(y) z experimentalu a updaty mozu byt automaticke. Zase nevyhoda je, ze update v ramci experimentalu moze prist bez toho, ze by si ho naozaj chcel/potreboval a moze to dokonca nechcene rozbit aplikaciu.

Nejaka univerzalna rada asi neexistuje. Ak mas ten system "zivy", v kuse na nom nieco robis, tak ti nevadi ak sa obcas nieco rozbije, pretoze to okamzite napravis a ides dalej. V tom pripade si mozes dat aj unstable spolu s experimentalom. Ale ak mas system produkcny, potrebujes aby to v prvom rade bezpecne slapalo a problemy po beznom malom update su nevitane, tak sa hodi stable vetva a aplikacia komplet pod tvojou kontrolou.
Ak to mas mat na jednom-dvoch svojich strojoch len so sporadickymi zmenami systemu/hardveru, tak je asi jednoduchsie si to vzdy skompilovat ked potrebujes (teda raz za cas) a potom uz len frcat. A ak to mienis distribuovat na vacsie mnozstvo strojov (ci nebodaj predavat ako sucast nejakeho riesenia), tak je zase lepsie vyrobit baliky pre vsetky cielove systemy a potom ich priebezne udrzovat...

S kniznicami to moze byt vselijako, zavisi od situacie:
1. Kniznica je sucast nejakeho balika => jednoducho nainstaluj dany balik
2. Kniznica je sucastou tej "homebrew" aplikacie (vsetko mimo akychkolvek balikov a mimo systemovych adresarov /usr/lib a /lib) => skopiruj spolu s aplikaciou
3. Kniznica je nejaka 3rd party, ktora nema ziaden balik (pravdepodobne stiahnute len zdrojaky a skompilovane na danej masine, teda bude niekde v /usr/local) => najjednoduchsie je zopakovat kompilaciu zo zdrojakov (bohuzial to potom treba robit na kazdom dalsom stroji kde to chces rozchodit; v takom pripade sa moze hodit vyrobit si balik aspon pomocou checkinstall)

Neviem, ci ten meraci program mas so zdrojakmi, alebo len binarku. Ak je to aj so zdrojakmi, tak najlepsie je skusit to cele skompilovat na novom stroji zo zdrojakov. Potom napisat do jedneho textaku ako na kompilaciu a zaarchivovat - toto by malo byt do buducnosti najprenesitelnejsie (teda nebudes zavisly od jedneho konkretneho systemu). Ako bonus by sa dal vyrobit debianovsky balik, ale to moze byt kus roboty (alebo aj nie, podla zlozitosti aplikacie). Ak nemas zdrojak, len binarku a navyse dynamicky linkovanu, tak je to z dlhodobeho hladiska problematicke (kniznice sa budu postupne vyvijat a casom by bolo vela roboty s dodanim starych kniznic do noveho systemu).

BTW: Ten "stary" stroj je tragicky neupdatovany (cisty Squeeze mozno uplne bez akychkolvek updatov, viac nez 2 roky stary), ale "novy" na tom nie je o vela lepsie (prvy update, ten uz asi tiez bude mat 2 roky). Je dost riziko pokusit sa k tomu dohodit nieco z experimentalu (moze to skoncit tak, ze bude vyzadovat vela novsich verzii balikov a ked to tam vsetko dohodis, tak si rozbijes cely system - napriklad Qt-kniznice su vyzadovane pre chod KDE prostredia). Takze ti fakt radim dat si tam najprv Wheezyho (a jeho najnovsie updaty: apt-get update && apt-get upgrade).

Nie nutne. Hardverove problemy sa prejavuju rozne. Uz sa mi napriklad stalo, ze sa mi stroj obcas nahodne restartoval. Ked som ho chcel preinstalovat, tak sa to pri instalacii zosypalo, vzdy na inom mieste (skusal som niekolkokrat). Nakoniec som zistil, ze je to zdrojom (pri instalacii sa toho vela kopirovalo naraz, disk zral viac, zdroj to uz neutiahol, disk sa odpojil a instalacia sa pochopitelne zosypala). Predtym v beziacom systeme sa s tym diskom tak kontinualne nerobilo, takze to robilo len raz za cas, pri instalacii to ale zblblo vzdy... Tiez som si vtedy najprv myslel, ze je zle instalacne CDcko...

Este sa mi osobne nestalo, ze by bol HW uplne v poriadku a system mrzol len chybou OS vzdy za inych okolnosti bez toho, ze by v logoch bola akakolvek zmienka. Vzdy v logoch bolo nieco, cim sa dal identifikovat problem: chyby generovane nejakym driverom, tainted kernel, CPU-throttling v dosledku prehriatia...

Ale pred vydanim Wheezyho bol nejaky problem v jadre 3.2 s akceleraciou na Intelackej grafike v Ivy Bridge procesoroch ktory sa prejavoval tiez mrznutim pri interakcii s grafickymi programami - podla popisu je to podobne tvojim problemom, vraj ani v logoch nic nebolo, len stroj zrazu vytuhol a nedalo sa s nim robit absolutne nic, okrem tvrdeho resetu. Bol to nejaky problem v jadre a od vyssej verzie, myslim 3.5, to uz nerobilo, do Wheezyho jadra debianisti potom pridali nejake patche a tym to opravili este pred vydanim Wheezyho... Nakolko je to naozaj spolahlive, to uz neviem (mam sice aj Ivy Bridge, ale nepouzivam v nom integrovanu grafiku, mam HD7970). Pozri sem, myslim ze to je ten bugreport: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689268, dlhe citanie, ale mozno tam najdes nejake finty ktore mozes vyskusat. Pripadne mozes skusit aj dat si novsie jadro 3.8 zo Sid-a...

Ked to zamrza kazdy raz v inom momente a v logu ani zmienka, skratka tuhy stroj, mal by som podozrenie aj na hardverovy problem (pamat, chladenie, napajanie, disk necakane odpojeny od SATA...). Urcite by som spustil memtest a mprime. Co sa tyka disku, tak by som pozrel SMART a spustil dlhy selftest a ak tam nie je SSD disk, tak aj badblocks (v nedestruktivnom mode).