Migrálunk, migrálunk...

Természetesen pár dolog azért akadt; néhány programot kézzel kellett fordítani, mivel kész csomag nem volt. Meg minden alkalommal, amikor a kernel frissült, forgatni kellett hozzá az NV drivert, a VirtualBox kernel-modulját, a CPLD/FPGA fejlesztő szoftver programozókábel-meghajtóját, talán mást nem. (Az első kettő mehetett volna a DKMS segítségével automatán is, de ezt meg nem szeretem. :) Illetve minden ilyen esetben legalább ránéztem, hogy van-e frissebb sofőr a videokártyához, ha igen, akkor abból azt raktam fel.) Szóval az elmúlt három év „unalmas egyhangúságban” tellett, minden csak egyszerűen működött. (Igen, lehet meglepő, de van ilyen is!)

A jelenlegi háttértár elmúlt 3 éves, ezalatt pörgött elég sokat. Épp itt az ideje, hogy ki legyen cserélve. (Ki mennyi időt ad általában egy HDD-nek? :) ) Az 500 GB-os példánynak sincs jelen pillanatban semmi baja, jó lesz majd „mezei” adattárnak rendszerlemez helyett. De visszafele csak nem fejlődök; az új példánynak egy 1 TB-os meghajtót néztem ki. Ez már egy Advanced Format-os meghajtó, ami a nagy többségnek valószínűleg nem újdonság, nekem még az. :) Abból a szempontból mindenképpen, hogy a particionálásnál oda kell valamennyire figyelni a határokra. Ez az odafigyelés mondjuk kimerült annyiban, hogy Fedora alatt az aktuális GParted-del készült el a felosztás, a jó öreg cfdisk-et hanyagolva.

A terv a következő lett: a két ünnepi „zabálás” között megejtem a két OS frissítését. Mármint frissebb verziókat telepítek fel egy új HDD-re, nem a régieket „ápgrédelem”. Lesz egy CentOS6 → CentOS7, meg egy Fedora20 → Fedora21 csere. Mivel új HDD-re megy a móka, a régin megmarad minden rendszerestől, ha valami probléma lesz, nem lesz miatta hajtépés. (Főszabály: legyen mindig „B” terv! :) ) Mert hogy kérdéses részek lesznek még akkor is, ha minden simán megy.

Első körben jött a Karácsony, utána a particionálás:

A két OS-nek (Fedora21 + CentOS7) két gyökérpartíció, köztük némi SWAP, a maradék meg jöhet a /home alá illetve egy „általános” tároló. Fájlrendszernek ext3 lett választva ext4 helyett. Ugyan a telepítővel majd ismét csak arra formáznám, amire akarom, ext3 marad! Az eddigi ext4-gyel ugyan nem sok problémám volt, de akadt egy furcsaság, amit nem tudok hova tenni. Egyszer régebben „megsérült” egy fájl. Ez egy sima .jpg kép volt, amit egyszer csak nem tudott a képmegjelenítő megjeleníteni. Majd a „közelmúltban” ugyanez megismétlődött egy .pdf-fel is. Mindkét fájl olyan, hogy ritkán voltak olvasva, cserébe (elvileg) semmilyen program nem írta őket. Természetesen nem tudom ráfogni tuti biztosan a fájlrendszerre, az viszont nem rémlik, hogy régebben lett volna ilyen problémám valamikor is. (A CentOS5-ön még ext3-at használtam, előtte sokáig a ReiserFS aktuális verzióját, a „régit”. De ilyesmi egyiken se rémlik...)

A telepítés(ek)ről kép nincs, sok érdekesség ott nem történt. (Talán csak annyi, hogy a CentOS7-nek csilli-villi új telepítője van, amit – természetesen – sikerült is először jól kiakasztani. :) ) Mindenesetre összejött, de a szépségek csak most jönnek. Grrr...

Első „kedvencem”: GRUB2. (A mostani mondatokat párszor átfogalmaztam. Az első verzió nagy részét ki kellett volna sípolni. :-D ) Eddig a „régi” GRUB-ot használtam, de a CentOS is áttért az új verzióra, a Fedora már régen, szóval itt nem volt választás. A GRUB1 esetén volt egy /boot partícióm, mindkét rendszer azt használta, ha valamelyik turkálni akart a boot paraméterek között, akkor a közösben meg tudta tenni. Ennek a megoldásnak – hála a GRUB2-nek – lőttek. Vajon minek kellett a GRUB2 konfigurációs állományait „begyógyítani” az OS fájlrendszerébe? Ami eddig jól működött, azt minek kellett megjavítani? (Tudom, naiv kérdések...)

De ez az egész Linux-boot történet számomra érthetetlen. Adva van ugye az MBR. Alapesetben az ebben a blokk(ok)ban levő kódot indítja el a BIOS a boot folyamat során. Az MBR-ben levő programnak az lenne a feladata, hogy az OS boot folyamatát elindítsa. Ha esetleg több OS is van az adott HDD-n, akkor ide jöhet egy menü, ahol a dear user ki tudja választani, mit szeretne tölteni. Ez a történet a GRUB1 esetén nagyjából kerek is. Ami már ott is el volt tolva (ez valójában az összes Linux betöltőnél el van...) az az, hogy szerintem az MBR-ben levő töltögető rutinnak semmi köze nem szabadna hogy legyen ahhoz, hogy az OS-t „milyen módon” (például milyen paraméterekkel) kell indítani. Neki csak annyi lenne a feladata, hogy az (éppen kiválasztott) OS saját rendszertöltőjét elindítsa. (A GRUB ezt a klasszikus chainloader sorral tudja is, szerintem a Linux-nak is ezzel kellene működnie.) Na, az OS saját rendszertöltőjének a feladata kellene legyen az, hogy milyen kernelt tölt, milyen paraméterekkel. Ehelyett meg mi van? Az MBR-be (meg most már egy csomó egyéb blokkba) kerülő kód lassan egy komplett operációs rendszer, ami „mindent akar”. Erre a GRUB2 még rá is tesz egy lapáttal az OS alatt levő konfigurációs borzalmaival. Valójában el kellene dönteni, hogy kinek mi a feladata. Értem én, hogy a GRUB2 akarja a Linux betöltését elvégezni, ebben az esetben ő lesz az OS töltőrutinja, cserébe semmi keresnivalója az MBR-ben. Meg akkor fölösleges neki más OS-t tudni tölteni. Ha meg a klasszikus „boot-menü” szerepet akarja, akkor meg semmi keresnivalója a beállításainak a majdan betöltendő OS fájlrendszerében. Ez az egész elképzelés így akkor működik jól, ha van egy Linux-od, amihez tartozik a GRUB2, aztán vagy semmi egyéb, vagy esetleg egy Windows® van még mellette (ezt lehet chainloader-elni). De amint ebből a konfigurációból ki akarsz lógni, onnantól kezdve értelmét veszti az egész. Egyébként természetesen tisztában vagyok azzal, hogy az egész töltögetést még jól megkeveri manapság az (U)EFI, ha jól sejtem a boot-menüs témát önmagában is képes lehet ellátni, de valahogy az sem az egyszerűség jegyében készült.

Nálam a telepítés úgy zajlott, hogy először felkerült a CentOS7, az szépen felpakolta a saját GRUB2-jét. Utána feltelepült a Fedora21, az szépen felülírta a saját GRUB2-jével a CentOS-ét. „Szerencsére” megtalálta a CentOS7 telepítését, így a hozzá tartozó pontokat felvette a saját menüjébe, de ahogy az a lista kinéz... :-D (Konkrétan tragikus.) Eddig ez szép és jó, viszont fogalmam sincs, hogy a későbbiekben mi fog történni. Ha a Fedora alatt kernel-csere lesz, az egyszerű, simán frissíti a (saját) GRUB2 beállításait. De mi lesz akkor, ha CentOS alatt lesz kernel-csere? Két verziót tudok elképzelni. Az egyik, hogy a CentOS újrapakolja a saját GRUB2-jét ilyenkor, ezután boot-kor mindig annak az OS-nek látom a boot-menüjét, amelyiknek frissebb a kernel-cseréje. A másik, hogy nem történik semmi, Fedora alatt majd kézzel update-elni kell a GRUB2-t, hogy a CentOS új kerneljét majd rakja be. Az egyik esetben cserélődik majd oda-vissza a menüben a sorrend (juhéj!), a másikban meg „kézzel” kell mindig matatni. Kiváló! Azért egy kis esélyt adhatok egy harmadik változatnak is: miszerint a GRUB2 valahogy rájön, hogy egy másik partíción vannak az aktuálisan feltelepített darab beállító fájljai, majd az alapján építi újra a menüt automatikusan. Azért ezzel kapcsolatban egy kissé szkeptikus vagyok, de ha ez így fog működni, akkor is meg lehet kérdezni, hogy mi a francot is kódoltak össze a GRUB2 kapcsán a programozók.

Na de elég a nyavajgásból (Tudom: csináljak jobbat... Szerintem simán lehetne mutogatni a jelenlegit egy „mit hogyan ne csináljunk” előadáson...), úgyis lesz még itt „izgalom”. A fő történet a CentOS...

Alapból nincs hálózat. Ez persze nem gond, de valahogy csinálni kellene. A szokásos parancs:

# ifup eth0
/sbin/ifup: a(z) eth0 konfigurációja nem található.

Grafikus felületen nem szokott az ilyesmi gond lenni, de én még nem tartok ott. Az ifstat nevű parancs ad egy statisztikát, ott kiderül, hogy ma a hálózati csatolót enp2s0 néven hívják:

# ifup enp2s0 
A kapcsolat sikeresen aktiválva (D-Bus aktív útvonal:
/org/freedesktop/NetworkManager/ActiveConnection/1)

No, ezek után már lehet frissíteni. Túl sok frissülés azért nem történt, de azért pár csomag akadt. Ami szükséges szokott lenni mindig, az nem más mint az EPEL repo. Például az általam favorizált Xfce is innen rakható fel a legegyszerűbben, egy yum groupinstall Xfce paranccsal. 4.10-es Xfce, szuper! Viszont meglehetősen „minimalista”, túl sok extra nincs hozzá... De ez egy „érdekes” tapasztalat az EPEL-lel. Valahogy sokkal kevesebb az elérhető csomag, mint amennyi a 6-os ághoz volt. Furcsa, egy csomó dolgot forgathatok magam? :)

A grafikus felület elindítva, de a régi problémám az egérrel itt is előjön. (A probléma dióhéjban: gagyi az egér firmware-je. Az üzemmódváltó gomb három gombot emulál, az egyiket mindig lenyomottnak mutatva. Ettől az X képes „megőrülni”.) Az install (-ok) alatt is előjött ez, átmenetileg egy másik egérrel megoldottam a telepítést. De jó lenne ha működne... Régen ezt egy Xmodmap fájl létrehozásával / feltöltésével oldottam meg, de az néha nem működött. Ekkor egy ki/bejelentkezés segített, de ha véletlenül megnyomódott a módváltó gomb, újra lehetett ki/bejelentkezni. :) (Szerencsére véletlenül nem egyszerű megnyomni, szóval ez nem volt annyira gáz.) De most meglett a „jó” megoldás! Mivel /etc/X11/xorg.conf fájl már itt sincs, ezért az /etc/X11/xorg.conf.d/910-rat.conf fájl lett létrehozva, benne a következőkkel:

Section "InputClass" 
    Identifier "R.A.T." 
    MatchProduct "R.A.T.7|R.A.T.9" 
    MatchDevicePath "/dev/input/event*" 
    Option "Buttons" "17" 
    Option "ButtonMapping" "1 2 3 4 5 0 0 8 9 7 6 12 0 0 0 16 17" 
    Option "AutoReleaseButtons" "13 14 15" 
    Option "ZAxisMapping" "4 5 6 7" 
EndSection

És igen, végre jól működik! Természetesen az üzemmódváltó az nem, de nem hiányzik. Illetve nyomogathatom ha akarom, nem lesz belőle „baj”. :) (Fedora21 alatt is ugyanez a feladat.) A megoldás egy Linux Mint-es leírásból van, ezúton is köszönet az eredeti szerzőnek!

Ezután kell a mókolt billentyűzetkiosztásom, az sima ügy, a megoldás itt is ugyanaz mint ott volt.

Na, jöhet az „alap” dolgok felpakolása, amire szükség van. Első körben kellene a „kedvenc” Xilinx-es fejlesztőkörnyezetem, az simán telepíthető, működik is. Persze a programozó kábel meghajtója nem települ (ez a CentOS6 alatt a vége fele már működött jól), túl friss neki a kernel. Ebből van friss(ebb) verzió is, meg lehetne próbálni felpakolni azt is. De az előzőleg használt user-space driver – annak ellenére, hogy elég régi – működik még mindig, annak a használatával meg egyáltalán nem kell kernel-modult forgatni. (Ha frissül a kernel, egy munkával kevesebb.) Ugyan néha „állásában” elszáll a letöltő alkalmazás, ;) de eddig még nem volt egyéb gondom vele, működik jól. A júzert hozzáadva az lp csoporthoz, egyből tudja sima felhasználóként is használni. De ha már hozzáadás, jöhet a dialout csoporthoz is, ekkor menni fognak a soros porti dolgok is.

Mi kell még? Egyelőre még mindig nem sikerült a kiköltözés az AMIGA emulátorból, így kellene nekem az is. Na, ez már keményebb dió; az eddig használt emulátorom, az E-UAE szépen segfault-ol indulás helyett. :( Az utolsó kiadás 2007-03-27 dátummal büszkélkedik, hát, az se ma volt. Az a csoda, hogy CentOS6 alatt még működött hibátlanul... Eddig saját fordítást még nem próbáltam belőle, most lefordítani sikerült, de ugyanúgy elesik induláskor. Barátom a kereső, sikerült egy másik emulátort találni, ami – úgy tűnik – most is aktív fejlesztés alatt áll. Ez nem más, mint az FS-UAE. Színes-szagos cucc, a fordításához kell az SDL-devel, openal-soft-devel, libX*-devel, meg sok egyéb, ami már fenn van. Lefordul, működik! :) (A forráscsomagban található egy fs-uae.spec nevű fájl is, azt odaadva az rpmbuild-nak simán készül belőle csomag. A fordítás amúgy egy sima make kiadásából áll, nincs configure script, ellentétben azzal, amit a doksi állít.) De azért vannak problémák. Alapból nincs beállító felülete, erre a célra az FS-UAE Launcher lenne való, de ahhoz meg python3 kellene, olyan meg mintha nem lenne még CentOS7 alatt. De ez megoldható, Fedora alatt lehet vele generálni egy alap beállító fájlt, utána azt már tudom itt is használni. A „Launcher” úgyis akkor lenne hasznos, ha sok fajta AMIGÁt akarnék emulálni, így több fajta beállítást lehetne egyszerűen kezelni vele. De itt erre nincs szükség. Viszont van egy eddig megoldatlan problémám is: lassú. :) Az oka is megvan: x86_64-es a bináris, amit fordítottam. (Nyilván, mivel az a használt OS is. Amióta tudok, azóta x86_64-et használok, de – meglepetés – a CentOS7-ből nincs is i686-os verzió!) Ez azért „probléma”, mert a 68K emulációból x86_64-re nincs elkészítve a JIT-es verzió. Persze a lassúság relatív:

Másfélszer gyorsabb még így is egy 68040/25MHz gépnél. De ennél ez gyorsabb is lehetne... :) Valahogy kellene egy i686-os verziót fordítani belőle, lehetőleg úgy, hogy a speciálisan használt könyvtárak statikusan legyenek hozzá linkelve. Na, ez egyelőre nekem nagy falat. (Mindig csak az a tanulás... :-| ) Mindenesetre emulátorom már van, majd csak el leszek vele valahogy...

Ha már emu. Egy kis „meglepetés”: az eddigi dolgokhoz nem kellett nvidia-driver. A rendszerben levő nouveau szépen teszi a dolgát. Erről először még itt a HUP-on olvastam valamikor jó régen (most így hirtelen nem is találom a hírt...), de úgy tűnik mostanra ért be annyira, hogy a gyári sofőrt el is felejthetem. (Még egy problémával kevesebb kernel-csere esetén.) Az mondjuk igaz, hogy egy régebbi (9600GT) videokártyát használok, de ez egyelőre rendben levőnek látszik.

További desktop-célú dolgok: kell az msttcorefonts, semmi extra telepítési probléma nincs. Aztán nem ártana valami médialejátszó... Audióra a DeaDBeeF-et használom, a sima, előre lefordított, statikusan linkelt verzió jól érzi magát az /opt alatt. Videóra jöhet a VLC, illetve néha azért jól jön az mplayer is. Ezekhez a dolgokhoz jól jön egy kis segítség a CentOS wiki-ből. (A keresgélés közben találtam utalást erre a nux-repo-ra, de ha nem látom a CentOS wiki-ben, nem biztos hogy merném használni. :) Alapból mindenesetre ki van kapcsolva.) A lista alapján feltelepült egy-két okosság is, például az IcedTea web-plugin is. Ezzel a verzióval működik az a webbank, amit használok, így a kézzel installált és frissített Java-plugintől is meg sikerült szabadulni. :)

Van képem meg hangom... De a hang az „érdekes”. Egyrészt beköltözött alapból CentOS7 alá a PulseAudio. Remek... Végül is működik (miután pár éve ki kellett cserélnem miatta az EMU10K1-es hangkártyám), de hang az csak az egyik csatornán szól. Ráadásul ugyanez van Fedora alatt is! Ami viszont nincs: pavucontrol. Valahogy kimaradt... A megoldás egy CentOS-os fórum: némi töltögetés meg telepítés után van hangerőszabályzóm... Azért úgy sejtem, ha nem Xfce-t akarnék használni, hanem megmaradtam volna a „gyári” GNOME / KDE vonalon (mindkettő „új” verzió, nem a világom...), akkor talán lenne valami mixerem alapból is. De a hang továbbra is féloldalas...

Miután a hangkártya-kimenet utáni hardverhiba ki lett zárva, előszedtem a jó öreg konzolos alsamixer-t. Vicces:

Igen, az alsa megörvendeztetett egy ilyen alapbeállítással, mindkét OS alatt. Gratulálok... :) Ezt korrigálva, már van normális hang.

Mi van még? Például kellene egy levelező is. Régen a KMail-t használtam, de voltak vele problémáim. Ez viszont jó régen volt, gondoltam adok neki újra egy esélyt. Hát, nem... Nincs KMail csomag. Valahogy kimaradt... Úgyhogy maradt az eddig úgy-ahogy bevált Claws Mail, legalább a levelek migrálását el lehet felejteni. (Sima copy, aztán megy minden, mintha mise történt volna.)

Vissza van a nyomtató: a yum install hplip-gui a gyógyír a dologra. A telepítés + konfigurálás után természetesen nem működik a nyomtatóm. :) Kell hozzá firmware, amit a hp-setup nevű util (hplip része) le is töltött. Hát akkor? :) A hplip része egy HP Device Manager névre hallgató eszköz:

Ezt elindítva lesz egy Download Firmware nevű pont. Na, az pontosan azt csinálja, hogy az eszközbe tölti le a firmware-t. Miután az megtörtént, utána – érdekes módon – egyből működik a nyomtatás. A szépséghiba csak annyi, hogy ezt minden kikapcsolt állapot után meg kell tenni, automatikusan nem történik meg, mint régen. A nyomtatót viszonylag ritkán használom, eddig még nem ért annyit a dolog, hogy utánanézzek a megoldásnak.

Lassan eljutok a történetben addig, ahol most tartok... Előző telepítésnél volt még egy szkájp installálásom, de azt kukáztam, amikor a kedves MS „bekeményített” a régi verziókkal kapcsolatban. Azóta a Jitsi-t használom, egy apró anomáliától függetlenül működik szépen. (A képernyő bal felső sarkában indulás után megjelenik egy „darab ablak”, benne az éppen ott levő képdarabbal. Nem lehet vele csinálni semmit, nem is akadályoz semmiben, csak ott van. Ez valószínűleg valamilyen Xfce ficsőr lesz, hasonlót tapasztaltam már másik programnál is néha, de eddig ritkán jött elő. Ez is képes eltűnni, szóval jó kérdés, hogy mi ez...)

Ami még vissza van: sok minden. :) Egyrészt hiányzik az avr-gcc, meg az összes kisegítő dolog hozzá. (Ezek eddig megvoltak az EPEL repóban, most fordíthatom majd ismét sk.) Aztán kell majd az avra, ez sem mai gyerek. Ráadásul az utolsó verzióban volt valami problémám a feltételes forgatással, szóval az még nem is jó. Az asl-t most felraktam, hogy a jó öreg vasaimhoz tudjak fordítani. :) Meg még ezer apróság, amik majd menet közben derülnek ki. („Ja, hogy ez sincs még felrakva...?” :) ) Ó, a „legfontosabbat” el ne felejtsem: nincs a networkmanager-hez az Xfce-ben semmilye applet, így a grafikus felületről nem tudom bekapcsolni a hálózatot. :)

Valami összegzés kellene ide a végére... A csere egyáltalán nem volt fontos. A CentOS6 a FAQ szerint 2020 November 30-ig kap frissítést, szóval akár még rá is értem volna. De azért a világ 6-os megjelenése óta nem állt meg, a frissebb alap meg sosem hátrány. Nagy átlagban rendesen működik a cucc (a Fedora-ról ugyanez elmondható, de ott más a cél úgyis), ami hiányzik, az meg majd szép lassan be lesz pótolva. Ha véleményt akarnék a 7-esről mondani, akkor talán egy kicsit félkésznek érzem az egészet. (Hogy ebből az Xfce-s mivolta mennyit számít, az jó kérdés, de szerintem benne van bőven.) Egyelőre marad, a marhaságokat majd megszokom, meg beszámolok a fejleményekről. :)

2015.01.30.

Az eltelt „néhány” napban történtek miatt célszerű kiegészíteni az eddigieket, mivel az ezer apróságból néhány dolog már meg is történt. Van network-manager-applet csomagban, valószínűleg nem pontosan ezen a néven kerestem, szóval a hálózat kapcsolgatása már megy GUI-ról is. (Igen, még mindig nem csatlakozok automatán! Direkt! :) ) Aztán felkerült pár csomag, amik most nem „vadászott” RPM-ből vannak, hanem magam forgattam. Ilyen lett (most is) az SDCC, de a hozzá szükséges gputils is saját fordítás, mivel (még?) nincs belőle csomag az EPEL-ben, mint régen. Aztán kellett az avra, eddig ebből nem volt csomagom (csak simán bemásoltam a /bin-be). Na, most már van... :) Ugyanebben a témában szükséges még az AVRDUDE is, ez is forgatódott. Amit viszont továbbra is a Fedora-ból vettem kölcsön, az a GtkTerm, a 21-es csomagja simán működik némi segítséggel. (Az előző verzió esetén is előszeretettel próbálgattam a Fedora különböző verziójú csomagjait, persze több-kevesebb sikerrel, de odafigyeléssel.) Ahhoz hogy a soros portot „mezei” felhasználóként is tudja kezelni, ahhoz a dialout csoporthoz hozzá kell adni a felhasználót. Illetve szeretne valamilyen lock fájlt is létrehozni, ehhez meg a lock csoporthoz kell hozzáadni. (De ezeket Fedora21 alatt is ugyanúgy meg kell tenni. CentOS6 alatt ez a lock csoportozás nem kellett még.)

A GRUB2 továbbra sem a kedvencem... A Fedora volt másodszor telepítve, így annak a boot-loadere az „aktív”. (Ha lehet így fogalmazni...) Emiatt a CentOS grub.cfg-jét töröltem, majd a Fedora (felcsatolt) partíción levő grub.cfg fájlt „be-symlink-eltem” a CentOS-os helyére. Ma volt „itt” is egy kernel update, úgy tűnik, hogy ilyenkor tényleg csak az emlegetett fájlt szerkesztgeti az update folyamat, bekerült az új bejegyzés. (Természetesen a sor elejére, lehet kézzel továbbra is szerkesztgetni a konfigurációs fájlt, mint a GRUB1 esetében. Csak itt sokkal ocsmányabb a szintaktika, nem kifejezetten „human-readable”.)

Két megoldandó feladatot látok még, amik nem lesznek annyira egyszerűek... Az egyik: néha jól jön a Wine. Ebből van az EPEL repóban csomag, csak az nekem nem jó. :) A CentOS7 csak x86-64 architektúrára jelent meg, nincs belőle i686-os verzió. Az EPEL-es Wine is x86-64-re van fordítva, aminek az a gondja, hogy nem futtat sima x86-os programokat. Pedig pont pár régebbi program esetében van esély arra, hogy használható lenne Wine segítségével, de azokból meg nem jellemző, hogy lenne x86-64-es verzió. Most – ha mégis nagyon kellene – megoldom a feladatot Fedora alatt, ott „teljes értékű” a csomag. Mindenesetre érdemes lenne valahogy CentOS7 alatt is megoldani ezt, de nem tudom mennyi esélyem van rá. :) A másik feladat az FS-UAE ugyanúgy i686-os verziója, a két téma szinte közös, ezekkel majd futkározok pár kört még, úgy hiszem...

Linkek:

• R.A.T.7 egér beállítása
• msttcorefonts telepítés
• FS-UAE, AMIGA emulátor
• Multimédia és egyéb desktop dolgok

balagesz

---

2015.01.11.
2015.01.30. Kiegészítések
2015.02.04. Javítás
2019.12.16. D8.