Egy HDD és vele együtt a komplett rendszer cseréje: kellett ez nekem?

 ( balagesz | 2011. szeptember 14., szerda - 20:46 )

Az előző háttértáram kezdett túlkorossá válni (ami egy ennyit használt félig mechanikus eszköznél gyorsan megesik), emiatt éppen itt volt az ideje egy cserének. A régi 320GB-os darab helyett lett egy még friss, ropogós 500GB-os példány. A réginek még nincs semmi baja, de ezt nem is akartam megvárni... Az új cucc kapacitása még elég nagy lesz nekem egyelőre, nagyobbat inkább nem mertem választani. (Szerintem nem is érdemes: az éppen aktuális legnagyobb kapacitású HDD-k a technológia határait teljesen kihasználják, ami növeli a hibalehetőséget. Persze IMHO, meg mindenki azt hisz amit akar, úgyhogy rám senki se hivatkozzon... :) )

Ha meg már HDD csere, akkor a jelenlegi rendszerek klónozása helyett jöhet egy új telepítés. (Az ilyen partíció-átméretezgetéses megoldásoktól úgyis fázok; gondom még nem adódott soha belőle, de ez szerintem csak azért van, mert összesen egyszer csináltam ilyet. Az ember ha a saját adataival játszik, talán jobban vigyáz... :) ) A „régi” meghajtón egy Fedora14 figyel egy CentOS5 társaságában, mindegyikből van már újabb. A Fedorából lassan (tényleg...) itt lesz a 16-os, és a CentOS-ból is már rég (hehe...) megjelent a 6-os változat. Ráadásul a CentOS5-öt valamiért nem tudom frissíteni; a YUM hibát ír.


Jól értem? Valami olyan problémája van, hogy a frissítendő csomagokhoz kell egy olyan csomag, ami már fel van telepítve. Angolul sajnos nem tudok, ha rosszul fordítom a hibaüzenetet, akkor nem értem, ha jól, akkor meg pláne...)

A két rendszert mar jó régóta használom. Konkrétan a Fedora 8 megjelenésétől kezdve. (Kb. 4 éve... Na, az ilyenektől szoktam kiakadni; mintha tegnap lett volna. Más is jár így, vagy csak én vagyok ezeken fennakadva?) Az okok pedig egy program futtatására vezethetők vissza, ez pedig nem más mint a Xilinx WebPACK. (A CentOS itt jön a képbe.) Abba most inkább nem mennék bele, hogy mekkora bloatware bughalmaz a cucc (mert IMHO az: a mostani utolsó verzió 5.5GB!), a mentségére szól, hogy van Linuxos verzió belőle. (Anno, amikor elkezdtem használni, az akkori verzió telepítője 47MB volt. A „cég” azért nem fejlődött akkorát, mint a „fejlesztőeszköz”, de mindegy. Akkor viszont még csak Windowson futott...) Bár az hogy „Linuxos”, egy kicsit erős túlzás, mivel a cucc igencsak Closed Source, a támogatott rendszerek kimerülnek a RHEL ill. SLED variációkban. De ez már igen komoly fejlődés... Amikor az első Linuxos változat megjelent, az egyetlen támogatott platform a RHEL3 volt. Kb. akkor volt ez, amikor a RHEL5-ös megjelent... Szóval nem sírunk! Persze hogy mi a támogatott, ill. min lehet működésre bírni, az két különböző dolog, kísérleteztem én ezzel UHU meg Gentoo alatt is, tulajdonképpen nem is eredménytelenül. De arra gondoltam, mi lenne, ha megnézném egy „támogatott” platformon, hátha a reszelés helyett ott csak egyszerűen „megy”. Ez a dolog a 11-es WebPACK verziótól kezdve nagyjából így is működik. Persze ehhez kellett a CentOS5, mivel a RHEL5 az támogatott verzió. Igazából egy problémás dolog van csak, az pedig a következő: a programmal CPLD-ket, FPGA-kat lehet fejleszteni. Ezeknek a „felprogramozásához” tartozik egy „letöltő kábel” (az általam használt változat a „Parallel Cable III” nevet viseli, egy egyszerű JTAG kábelről van szó), amivel a feladat elvégezhető. Ehhez a kábelhez meg tartozik egy kernel-modul, hogy tudja kezelni a program. Innentől kezdve lehet vigyorogni, mivel ha Linuxon valamihez kernel-modult kell külön forgatni, az csakis és kizárólag szívás lehet... :) Hát, itt is az. CentOS5 alatt viszont simán működött. (Ugyanaz a kernel verzió van benne, mint az aktuális RHEL-ban, a többi ugyebár egyértelmű.) Ezután összeszedtem az összes feladatot, amihez MUNKA miatt kell az OS, és CentOS5 alatt nagyjából mindent sikerült is megoldani, a stabil működése meg igencsak megtetszett... Így ez maradt munkarendszernek. A Fedora meg jó lesz szórakozni... :) (Fél évente új verzió, mindenből szinte a legfrissebb, szép kaland.)

Tehát adott a feladat: ha a WebPACK-ot CentOS6 alatt működésre tudom bírni, az összes többi problémám megoldható. Mégis csak újabb verzió van benne mindenből mint az 5-ösben, a külön forgatandó programoknál tuti jóval kevesebb a szívás... Motiváció tehát van. De szívás is lesz, ezt valahogy éreztem. Sajnos az érzéseim nem csaltak, már a RHEL se a régi..? Egy másik újdonság is azért közrejátszik: eddig a CentOS az x86-os változat volt, én meg szeretnék helyette x86-64 verziót. Mivel igencsak rühellem az x86 architektúrát, de ez most itt erősen offtopic...

Először mindkét rendszert kipróbáltam Live médiáról, hogy valami minimális képem legyen arról, mit is akarok telepíteni. Már itt kiborult egy hiba, rosszul működik az egerem. Valahogy elveszik a fókusz, nem mindig lehet klikkelni abban az ablakban, ami meg van nyitva. Vannak olyan gadgetek, amiket nem lehet kiválasztani. Ablakot nem lehet áthelyezni, fókuszt nem lehet váltani... Igen érdekes hibajelenség, leírni se tudom... A poén: mindkét próbált OS (F15, CentOS6) ugyanezt produkálja. Ablakkezelőtől függetlenül. De az egér „jó”: a régi OS-ek alatt hibátlanul dolgozik. Másik USB-s egér itt is hibátlan. Ilyenkor mi van? A barátom, a google azt mondja, hogy nem vagyok egyedül, sok-sok esetben előforduló problémáról van szó (ezzel a típusú egérrel, természetesen), leginkább Ubuntu-s hibaleírásokkal találkozni, de disztribúciófüggetlen a jelenség. Hogy a hiba hol van (kernel, xorg, vagy maga a hw, esetleg kombinált), az még eldöntendő, de érdekes dolgokra derült fény... Az egér firmware-je bután van megírva. Van egy „mode” gombja, ami egyszerűen nem küld felengedés kódot a rendszernek, ráadásul mivel 3 üzemmódja van, így 3 fajta gomblenyomást küld, amikor a drága júzer nyomkodja. Amikor először nyomom, küld egy 13-as gomb lenyomás kódot. Ha másodszor nyomom, küld egy 13-as felengedés, 14-es lenyomást. Utána 14-es fel, 15-ös le-t, majd 15-ös fel, 13-as le-t... Szóval a rendszer felé mindig van egy lenyomott gomb-állapot. Ez kiakasztja az X-et? (Hogy mit szívhatott a drága programozó, aki a fw működését kitalálta, arra nem derült fény. De jó anyag lehetett, ha ekkora marhaságot megcsinált...) Megoldás nincs, workaround van, több fajta is. Majd később visszatérek rá, egércsere, jöhetnek az installok...

Maga az install a két esetben eltér, mivel a F15 Live alól szinte csak másolás ment, csomagokat ott nem lehet választani (legalábbis nem rémlik... :) ), ellentétben a CentOS6-tal, ahol a jól megszokott anaconda teszi a dolgát. A két OS egy közös boot partíción osztozik, hogy az esetleges kernel-frissítések grub.conf módosításai ne okozzanak külön fejfájást. (Régóta működő, jól bevált technika.) Remélem a „régi” grub még támogatott lesz egy darabig, na AKKOR lesz majd sírás, ha a Fedora átáll a grub2-re. Az install vagy 3-ikra sikerült „normálisan”, tulajdonképpen nem is tudom hogy mik voltak a nyűgök, de az UUID-s partíció azonosítással még mindig bajban vagyok... (Mindkét telepítéshez „custom” partíció-kiosztást használok, ez meg valószínűleg újragenerálja az UUID-s azonosítókat.) Gyorsan csináltam LABEL-eket a partíciókhoz, az fstab-okban meg kijavítottam a hivatkozásokat. Az alaprendszerek működnek, mindenki happy...

A CentOS a fontosabb a meló miatt, ezért annak a „belakásával” kezdődött a problémahalmaz. Először is: küzdjünk meg az egérrel... A neten fellelhető tippek tulajdonképpen működnek is, meg nem is. A közös bennük az, hogy a 13-14-15 számú egér-gombokat kitiltják a működésből. Van egy olyan megoldás, hogy egy Section ”InputClass” részt kell az xorg.conf-ba illeszteni. Fail: nincs xorg.conf file. Sebaj, az NVidia sofőr majd csinál, akkor először azt kell felrakni. A nouveau dirvert ki kell tiltani (kis grub.conf paraméterezés: nouveau.modeset=0 rdblacklist=nouveau szöveget be kell írni a kernel... sorba paraméternek). Felment rendben, VAN xorg.conf-om! Szuper! Beleírva az ”InputClass” sorokat, nem indul az X, a logban hisztizik rá, hogy a beillesztett Section-t nem ismeri. A ”ButtonMapping” sort berakva az ”InputDevice” Mouse részbe, a probléma megoldódik. Remek! Viszont van egy bökkenő: ha újraindítom a gépet, újra rossz lesz. Ha kijelentkezek meg vissza, rendbe jön... Ha boot után, amikor a GDM elindul, ott nyomok egy Ctrl+Alt+Backspace kombót (újraindul az X), akkor utána bejelentkezve már jó. Viszont van egy másik megoldás is, ahhoz az Xmodmap-ba kell beleírni a következő sort:

pointer = 0 1 2 3 4 5 6 7 8 9 10 11 12 0 0 0

Ez mindegy, hogy az /etc/X11/Xmodmap file-ba kerül, vagy a júzer home könyvtárába egy .Xmodmap beállító file-ba, mindkét esetben működik. Pontosan úgy, mint az xorg.conf turkálása esetén: boot után kell egy X restart, hogy jó legyen... Ha erre lenne valakinek ötlete, azt szívesen meghallgatom! :) (A helyzet tök ugyanez F15 alatt is, de ott legalább az ”InputClass”-féle megoldás is ~működik.

Mivel a CentOS6 is áttért a 4-es KDE-re, nekem meg az „nemgyerebe” kategória, egy ideje Xfce-t használok. A yum groupinstall XFCE parancs meglepő módon „hatástalan”, nincs a CentOS6-ban Xfce... Hát, forgassak ezt is magamnak? Ez az én tudásomhoz képest nagy falatnak tűnik, de majd csak lesz valami... Viszont ért egy kellemes meglepetés. Már az 5-ös alatt is „nélkülözhetetlen” volt az EPEL repo (Extra Packages for Enterprise Linux), így „feltelepítettem” a használatához szükséges csomagot. Az Xfce hiánya másnak is feltűnt, így az EPEL csomagok között ott van... Ráadásul a 4.8.0-ás, ami még friss is! (Persze ez már nem „Enterprise” szoftver, erre nem árt figyelni...) Sőt! Egy csomó másik csomag, pl. az avr-gcc és sallangjai is ott vannak, amiket az 5-ösnél még saját magam küzdöttem föl... Azt hiszem kezdem szeretni a 6-os CentOS-t... :)

Szóval Xfce felment, a terminál-emulátorában nem látszik a kurzor. Bravó... Google: valamilyen ismert bug, rengeteg okoskodás után egy használható workaround:

~/.config/Terminal/terminalrc file-ba a következő sort bele kell írni:

ColorCursor=

Így, paraméter nélkül. A kurzor így szép szürke lesz. A színe nem állítható, de legalább látszik... :) De ha már terminál meg billentyũzet: VÉGRE alapból bekapcsolódik boot után a NumLock. Hogy mit kellett ehhez 2011-ig várni... :)

Sajnos vannak az Xfce-nek más hiányosságai is. Kellene néhány paneles plugin, ami hiányzik az EPEL-es csomagok közül. Ilyen például az xfce4-xkb-plugin, amivel billentyűzet-kiosztást lehet kapcsolgatni. Egyelőre csináltam egy szkriptet, ami a setxkbmap segítségével ciklikusan kapcsolgatja azt a 3 fajta kiosztást, amit (néha) használok. De ez csak egy workaround, majd megpróbálom leforgatni a plugint, mivel nem csak ez hiányzik. Még mindig töredéke mondjuk annak a feladatnak, mintha az egész Xfce-t forgatni kellene...

Akkor jöhet a WebPACK install próba. 5.5GB kicsomagol (Ez egy jó poén: a letölthető „csomag” egy .tar archív. Ebben van a Windows-os installer is... Kicsit „típusidegen” ez a formátum ott, de írják is, hogy (talán) a WinZip / 7Zip ki tudja csomagolni... :) ), install elindít. Ez már szerencsére támogatja a 64 bites OS-t is. Most konkrétan a 13.2-es verzióról van szó, és ez már az /opt alá települ alapból, nem a felhasználó home-jába. :) A szokásos kérdések után szépen felkúszik... Persze a „Cable Driver” fordítása elhasal. Még természetes, azért akarok RHEL klónt használni, hogy ne legyen ilyen gond... Hát, izé... Van. Ugyanis a „szupportált” OS-ek között a RHEL4 ill 5-ös verzió szerepel csak. Mégse szeretem a CentOS6-ot?

Persze van megoldás, még akkor bukkantam rá, amikor Gentoo alatt kísérleteztem a cuccal. (A Gentoo wiki sokszor segített már ki, disztribúciótól függetlenül.) A „gyári” kernel-modul forgatása mindig nyűgös, így egy jóember írt egy user-space drivert, amivel az alap funkciók használhatók. Nekem meg pont azok kellenek...

Le kell tölteni az usb-driver-HEAD.tar.gz file-t az oldalról, kell hozzá a libusb-devel ill. a libftdi-devel csomag (ezek a „gyári” repókban megvannak). A driver-t ki kell csomagolni, majd egy mezei make a könyvtárban lefordítja egy pillanat alatt. (Azok a „devel” cuccok, mint gcc és társai, már az NVidia driver forgatásánál kellettek, úgyhogy pontosan nem tudom mik használódnak, de a gcc, binutils, ill. a make biztosan...) A végeredmény egy libusb-driver.so nevű file-ban jelenik meg, ezt én bemásoltam a /usr/lib64 könyvtárba. A file neve ne ijesszen meg senkit: ez a cucc nem csak az USB-s JTAG kábeleket kezeli, hanem a párhuzamos portosokat is, amilyet én is használok. Ehhez a ppdev kernel-modul kell, de az meg benne van a CentOS6-ban.

A cucc használatához az kell, hogy a programozó SW indítása előtt ezt a libet be kell tölteni. Az eredeti cable-driver esetében is ez volt a szituáció. Ott ez úgy van megoldva, hogy az a script, ami a driver fordítását végzi, az belerakja az /etc/rc.d/rc.local file-ba a driver betöltését, ami boot végén lefutva létrehozza a /dev/windrvr6 eszközt, ezt matatja a program. Viszont az eszköz root:root tulajdonossal/csoporttal jön létre, rw jogokkal a tulajdonosnak, másnak semmi (600). Ahhoz, hogy a júzer is tudjon „letölteni” root jogok nélkül, rw-rw-rw- (666) kellene, egy /bin/chmod 666 /dev/windrvr6 sort célszerű a modul betöltése UTÁNRA beleírni még az rc.local-ba. Kernel frissítés esetén a drivert újra kell forgatni, a script újra beírja az rc.local VÉGÉRE a (z új kernelhez való) modul betöltését, természetesen a chmod utánra, ami így nem is fog működni, lehet kézzel újra szerkesztgetni az init szkriptet. (Ez az a szituáció, amikor szupportált OS-t használsz, és minden működik. :) )

Ezzel szemben mi a helyzet a mostani megoldással? Nálam a párhuzamos portos kábel használódik, ahhoz a /dev/parport0 elérése kell. Annak a „gyári” jogosultsága rw-rw---- (660), az lp csoport tagja, ergo elég a júzert felvenni az lp csoportba, és már tudja is használni. A program indításakor egy „beállító szkript”-et úgyis végre kell hajtatni, emiatt készült egy egyszerű kis indító, amibe az user-space cable-driver „betöltését” is beleraktam. Ez a startise.bash nevet viseli, és a következőt tartalmazza:

#!/bin/bash 
export LD_PRELOAD=/usr/lib64/libusb-driver.so 
source /opt/Xilinx/13.2/ISE_DS/settings64.sh /opt/Xilinx/13.2/ISE_DS/ 
ise 

A második sor a „driver” „betöltése”, a harmadik az indítás előtti „beállítás” (ezt a WebPACK telepítője a végén közli is), a negyedik sor magának a fejlesztőszoftvernek az indítása. Van még egy másik ilyen indító szkript, amivel CSAK a letöltő szoftvert lehet elindítani (iMPACT), ennek a neve startimpact.bash lett. Az az előzőtől annyiban különbözik, hogy a 4-edik sorban NEM ise szerepel, hanem impact. (Ha frissül a WebPACK, az újabb könyvtárba fog telepedni, a „beállítás” elérési útja is változik, ezeket a két szkriptben majd ki kell javítani. Ha csak át nem kavarják az egészet...) Ez a két file beugrott az /usr/bin könyvtárba, csináltam hozzá két ikont amivel indítani lehet, és ennyi. Nincs kernel frissítésnél újraforgatás, rc.local szerkesztgetés, semmi. Csak megy. Megy?

Igen, működik. Vajon a letöltő szoftver is üzemel? Ami miatt az egész driveres móka van?

Hát, úgy tűnik... Egyelőre nem teszteltem agyon, de arra is sor fog kerülni.

Végre, kezd olyan érzésem lenni, hogy mégiscsak jó lesz ez nekem. Mi kell még? Kell nekem (most nem részletezett okból) az E-UAE, a jó öreg AMIGA emulátor 32 bites verziója. (Mivel a JIT-es 68K emu nincs x86-64 verzióban elkészítve.) Ehhez kellett pár 32 bites lib (SDL és társai...) de utána simán működik a lassan 4 és fél éves bináris... Ilyen is van?

Mi van még, ami érdekes? Mondjuk a nyomtató. Egy „jó”, „öreg” hp gazdaságos lézerrel áldott meg a sors (hp LaserJet 1000), amiben nincs firmware (csak egy kicsi...), tehát azt is a gép tölti bele bekapcsoláskor. Ezt CentOS5 alatt nem tudtam életre kelteni, ott túl régi a HPLIP... Itt vajon mi a helyzet?

A hp-setup programocskát elindítva, szerencsére jön a szokásos rész:

Miszerint ő akkor most le szeretné azt a fw-t tölteni a HP szerveréről, ami a nyomtatóhoz kell. Hát, töltsd! Lejött, nyomtató „zörgött” egyet, amikor belekerült a cucc, tesztoldal kijött, OpenOffice-ból nyomtatás működik... Ez is letudva. (Egyik kollégámnak is ugyanez a nyomtatója volt. Win alatt eszméletlen mennyiségűt görcsölt a telepítéssel: amikor elindítod a telepítőt, ne legyen bedugva, majd amikor szól, akkor dugd be, ... Ehhez képest itt a Windows-only nyomtató telepítése gyerekjáték volt. :) ) Sőt: túlélte a „Reboot próbát” is! (Voltam már úgy, hogy az ilyesmi csak az első újraindításig működött, utána soha többet...) Vajon miért nem működik minden így?

Jól jönne még a Skype is... Ez is 32 bites ugyebár. A Skype oldaláról letöltött Fedora-s csomaggal próbálkoztam először, ehhez fel kell rakni a következőket:

  1. qt.i686
  2. qt-x11.i686
  3. libXv.i686
  4. libXScrnSaver.i686

A yum most is segít, ezek csomagban megvannak, ezután már fölmegy a Skype.rpm. Elindulni, na azt nem... :) Az okot nem tudom (Első induláskor a licencet el kéne fogadni, az ablak egy pillanatra megjelenik, majd segfault...), de a static változatból kiszedett binárissal felülírva a csomagból telepítettet, megy. Nem egy szép workaround, nem is vagyok rá büszke...

Kellene még a böngészőhöz Flash ill. JAVA plugin. Flash esetén segítség a Fedora-s leírás: a Fedora Flash-Player doksiból a „natív” 64-bites rész a nyerő, megy is szépen. (CentOS5-ön valami miatt esett-kelt az aktuális plugin, a FlashBlock kiterjesztés erősen kötelező volt, de az most is az lesz!) A JAVA is egyszerű, ezen leírás alapján simán működésre bírható. Ebben az a jó, hogy CentOS5 alatt ez se működött valamiért, mondjuk annyira nem is másztam bele a témába. Ezek szerint nemsokára lesz HUP-os JAVA-mikulásom? :) (Remélem idén se marad ki!)

Mi van még vissza? Van egy „csodálatos” Logitech G15 billentyűzetem (link most nincs, mivel a Logitech oldalán már nem is találom az eredetit...), azon van egy csomó plusz billentyű ill. egy LCD. (Ahhoz képest, hogy EGYÁTALÁN nem játszom a számítógépen, ez már a második „gaming” periféria... Tulajdonképpen azt kell mondanom, hogy ez sem volt jó választás; a szokásos jó ötlet jól elcseszett megvalósítása, mint az egér eseteben... Több „játékos” cuccom NEM lesz! :) ) Szerencsére van némi Linux szupport, persze nem gyári. Ez is user-space program, az uinput-on keresztül működik. A G15Daemon a „fő” komponens, viszont a fordításához kell pár lib. Ezzel (mármint a fordításával) már párszor megküzdöttem, elég unalmas... De mindig elfelejtem, hogy mit, milyen sorrendben kellene fordítani, mivel egymásra épülnek. Négy fordítandó csomag van, a libg15, a libg15render, a g15daemon ill. a g15composer. Ezeket ilyen sorrendben kellene fordítani. A libg15 önállóan fordul, a libg15render-nek már szüksége van az előzőre. A g15daemon-nak meg mindkettőre, ez a „fő” komponens amúgy, ennek a segítségével kezelhetők a plusz gombok, ill. az LCD maga. Tartalmaz pár pugint, ilyen például az óra, ami alapból a kijelzőn megjelenik. Végül jön a g15composer, ez ahhoz kell, hogy a kijelzőt külső programok tudják használni. Van jó pár ilyen külső programhoz készült plugin, pl. xmms, audacious... (Régen használtam is őket, de egy ideje leszoktam a forgatásukról, mivel csomagban ezek sincsenek... De majd most! Most? :) ) A négy komponens forgatásához nekiálltam készíteni egy szkriptet, működik is szépen, csak van egy „apró” bökkenő: a lefordult cucc nem működik. Remek... Ugyanis vannak problémák: A „pakkot” nem készítették fel 64 bites rendszereken való fordításra. (Létezik ilyen, vagy ez a normális, és máshogy oldják meg a kérdést?) A lefordult libek az /usr/lib alá települnének az [/code]/usr/lib64[/code] helyett. De ezen lehet segíteni szerencsére, ill. valószínűleg ez csak esztétikai probléma (32 bites libek között ott vannak a 64 bitesek...). Az igazi gond akkor derül ki, ha debug módban indítom el a g15daemon-t (# g15daemon -d), ekkor ugyanis kiírja, hogy nem tudja megnyitni a plugins könyvtárát, amibe a kijelző „programocskái” vannak. A fordítást a szokásos ./configure --prefix=... módon csináltam meg, hogy ne szemetelje össze a rendszerkönyvtárakat, viszont ettől meg a „munkakönyvtár” címe „beégetődött” a lefordított programba, és ott keresné a plugineket... Ráadásul az a könyvtár még (egyelőre...) ott is van! Izé... Most... ...sikítsak? (Az is lehet hogy ez így természetes. Nem értek én ehhez se...)

Egyelőre a megoldás a manuális fordítás lett, az összes cuccot a ./configure --libdir=/usr/lib64 módon kellett konfigurálni, utána make, a végén meg root-ként make install. Utána már szépen elindul. De ez megint kézzel megy, nincs csomag, csinálhatom ugyanezt F15-ön is... Jaj. Az indításához létezik olyan megoldás, hogy a g15daemon az eszköz bedugásakor induljon automatikusan, egyelőre én beleraktam a betöltését bután az rc.local-ba. Nem szép, de legalább csúnya.

Most már „lassan de biztosan” haladok abba az irányba, hogy összeáll minden, amit a régi OS alatt használtam, működik... A végére kéne valami konklúzió. Jó-e nekem a CentOS6? A nyűgjein lassan túljutok, és ha ezt is annyi ideig fogom használni mint az 5-öst, akkor kezd tetszeni... Azért a „vérfrissítés” már igencsak ráfért a cuccra, mivel Linux alatt az avulás a megszokotthoz képest is gyors. Az 5-ös azért már igencsak öregecske... Jó ez akkor nekem? Most azt mondom: igen... (De csak halkan suttogok...)

balagesz

---

2011.09.14.
2015.01.30. Hibajavítás

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

> Az előző háttértáram kezdett túlkorossá válni ... A régi 320GB-os darab helyett lett egy még friss, ropogós 500GB-os példány.

Most egy pillanatra elgondolkodtam azon, hogy le kellene-e cserélnem a 110.000 üzemórás diszkjeimet:

sd0 at scsibus0 target 0 lun 0: <QUANTUM, ATLAS_V__9_WLS, 0230> disk fixed
sd0: 8755 MB, 20907 cyl, 2 head, 428 sec, 512 bytes/sect x 17930694 sectors
sd0: sync (12.50ns offset 63), 16-bit (160.000MB/s) transfers, tagged queueing

Aztán rájöttem, hogy ezek tök korszerű Ultra160-as cuccok, mikor még narrow 20MHz-es vasak is vannak forgalomban :)

Egy "mai", olcso cuccot nem erdemes osszehasonlitani egy SCSI diszkkel. Ha mar regiseg: ilyenkor mindig eszembe jut az elso sajat IDE-s HDD-m, az egy 3.5"-os dupla magas 40MB-os diszk volt. Rogton csinaltam ra 2 particiot... :) Itt is van egy dobbenetes adat: a kapacitas ahhoz kepest ropke 12500-szoros.

Megj: persze az a 40MB-os diszk tokeletesen mukodik meg ma is.

„Rogton csinaltam ra 2 particiot”

Egy 32 MB-osat, meg a maradékból egy logikait az extended-ben :)

Köszi :)

Nincs mit. :)

"az éppen aktuális legnagyobb kapacitású HDD-k a technológia határait teljesen kihasználják, ami növeli a hibalehetőséget"
Ha van is benne igazság, azért ennél több utánajárást igényel. A technológia határait úgy feszegetik, hogy egyre nagyobb bitsűrűséget érnek el. A legnagyobb hdd-kben több lemeztányér van, a kisebbekben sokszor ugyan abból a lemeztányérból van kevesebb (nem éri meg több félét gyártani). Ha jól tudom, mostanában sikerült elérni a gyártóknak a 750GB-s tányért, előtte az 500-as volt az elterjedt, nagy valószínűséggel a te lemezedben ugyan olyan tányér van, mint egy 2000GB-os modellben. Persze a kevesebb lemeznek is van előnye, általában csendesebb, hűvösebb, kisebb az esély mechanikai hibára, de a lemeztányér sokszorozása nem éppen új technológia.

már van 1GB/lemez.

Igen, ez kenyes tema, sokszor kepzi hitvita targyat. A nagyobb surusegu tanyernak megvan az az elonye, hogy ugyanakkora lemezforgasi sebessegnel nagyobb lesz az atviteli sebesseg a kisebb suruseghez kepest. Remelem is, hogy az enyemben 1 lemez van... :)

Miazhogy. De már van 1 TB/lemez is... :)

Xilinxhez nem kell az userspace usb-driver. Scientific Linux 6.1-en úgy oldottam meg, hogy a legfrissebb libusb-t (az 1.manótudjahanyast) belinkeltem a /usr/lib/libusb.so-ra.

Szerk: Ja, parport, visszavontam.

Igen, ez a kabel meg akkori, amikor kuriozum volt az USB... :) De ezt a tippet megjegyzem a kesobbiekre.