Most, hogy megérkezett a 3.0.0 (Aki nem tudja, hogy miről beszélek, ne is olvasson tovább. Vagy csak saját felelősségére. De arra is minek?!), és Debianék (Ha még ezt sem ismeri, akkor tényleg ne.) is szépen felpatchelték, becsomagolták, én meg letöltöttem, kicsomagoltam és kicsit átnéztem a konfigot (tényleg csak kicsit, mert "make oldconfig"-hoz se volt türelmem...) már kezdtem is magamnak fordítani. És mivel ezen az egy gépen fog csak futni, lentebb látható módon beállítottam egy környezeti változót, ami hatással lesz a fordításra. Az első sor, amit kiírt, ez volt:
Makefile:655: "WARNING: Appending $KCFLAGS (-march=native -mtune=native) from environment to kernel $CFLAGS"
Ez miért warning?! Azért van a KCFLAGS, nem? Mondjuk kedves tőle, hogy szól, (pedig csak tudom már, hogy milyen [ehhez hasonló célú] környezeti változók vannak hogyan és miért beállítva...) de hogy csupa nagybetűs WARNING volna?!
Mindegy, ő tudja, csak megakadt rajta a szemem. Olyannyira, hogy ezt kiírtam ide. Hogy miért nem máshova, a blog első posztjában van leírva.
(Megj.: "make -j 8"-at indítottam [Mert az jó. Meg miért ne.] egy 1.8 GHz-es "Mobility" Athlon X2-n [TK-55], és VLC-ben a netes audiostream meg se röccen, compiz sem akad, Chromium sem érzi, szóval a scheduler [CFQ, de nem tudom, hogy a többi milyen lenne] már 2.6.38-ban is jó volt. Meg PREEMPT, meg automatic process grouping, meg 1000Hz, meg miegymás.)
2011. júl. 28.
2011. jún. 17.
HDR-szerű kompozíció Blenderben
Nem értek a fényképezéshez, ezért nincs is semmilyen felszerelésem, de az sokszor zavart, hogy a kis kompakt gépem (na jó, tesómé, egy Canon PowerShot A470) vagy a sötét dolgokat látja, vagy a világosakat. Vagy kiégnek a fényes részek, vagy eltűnnek az árnyékosak. Ez ugye azért van, mert sokkal kisebb kontrasztarányban érzékel a CCD, mint a szemünk. Ez meg azért van, mert a sok okos vásárló mindig csak a minél több megapikszelre ugrik, ezért csak a felbontás növelésére gyúrnak egyes gyártók az olcsó gépekbe kerülő chipeknél, a minőség (kontrasztarány) már nem annyira számít nekik.
Erre van egy olyan megoldás, hogy 3 (vagy 5 vagy 7 vagy 9) különböző expozícióbeállítással (EV) kell ugyanazt lefényképezni, és az alulexponált képből a világos részek fognak a kívánt képre kerülni, a túlexponáltból meg a sötétek. (Nem, nem fordítva.) Ami meg jó az automata érzékeléssel készültön, az maradhat úgy. Így tehát jó lesz a sötét meg a világos rész is, mintegy 3 kis "fényességsávból" 1 nagyobbat összevágva, majd összezsugorítva azt, hogy látszódjon a monitorokon. Persze auto bracketing nincs ebben a gépben, szóval autóversenyzésről nem fogok tudni ezzel ilyen képeket csinálni (Bár azt mondják, rawból elég egy kép is, és utólag lehet expozíciót állítani! :O Én nem tudom...), de tájakról még csak-csak. Állványom sincs, szóval majd leteszem az asztalra a gépet, vagy hozzáfogom egy faághoz. Nyers képeket nem tudok készíteni, tehát marad a JPG, ami már alapból csúnyácska, de színe még azért csak van valamilyen. Ezek csak az én problémáim, itt jön a lényeg:
Vannak direkt erre a célra kitalált programok, mint a Photomatix, vagy a Qtpfsgui. Photoshoppal, mint mindent, ezt is lehet. GIMPpel már annyira nem, mert azt mondják, az csak 8 bites képekkel dolgozik, és ennek 32 kell. Én ezt sem tudom, csak úgy olvastam. De azt tudom, hogy a CinePaint egy GIMP fork, amiben van 32 bites képfelbontás (úgy értem csatornánként), és néhány profi is használja. Csak nincs Windowsra, de az nekem mindegy.
A Photomatix drága, vagy próbaverziós, nem próbáltam ki. A Qtpfsguiban nekem első pillantásra sok volt a tekerentyű, huzogantyú meg választóka, és default beállításokkal nem volt jó (Programtervezési megjegyzés: Minden alkalmazásnál fontos a jól megválasztott default konfiguráció, hogy a kezdők, programmal épp csak ismerkedők egyből, mindenféle piszkálgatás nélkül használható outputot lássanak, még ha nem is tudják beállítani a programot, ami esetleg akkor már használható volna, ha jól lenne beállítva, de alapból nem jól van. Ha elsőre nagyon rosszat látnak, az baj.). GIMP-ben macerás meg időigényes volt egy-egy közbenső lépés finomítása, undo-redo, a maszkok beállítása, csatornákra bontás, visszakeverés, rétegezés, miegyéb. Ezen problémák kiküszöbölésére, és egy folytonosabb munkamódszer megteremtésére meg már csak a "csakazértis, mertmiértne" elv alapján, egészséges kíváncsiságból jutott eszembe, hogy a Blender tud node alapú kompozitálást. Tehát nem kell undozni, hanem minden változtatásnál újból lerendereli az egészet, és annyit meg tud a képeken bűvészkedni, ami nekem ehhez kellett. Maga a kompozitáló modul is tud fájlból több képet beolvasni, kiírni, meg menet közbeni képekbe is be lehet kukkantani. Egy szóval: tökjó.
Maga a módszer a maszkolásos keverésen alapszik, a maszkokat meg a képek fényereje szolgáltatja. Innen letölthető a .blend fájl. (Készült 2.57b verziójú Blenderrel.)
És így néz ki:
(Igen, kicsit "szellemes", mert a 3 kép nem pontosan fedi egymást, erre fényképezéskor figyelni kell. Az esetleges elő- vagyis inkább utóigazítást előre [Na, mégis "elő-"?] el kell végezni egy másik programmal. Mondjuk GIMPpel. Vagy ami jól esik.)
A bal oldalt lévő két számbemenet közül a felső egy korai relatív átméretezés mindkét tengely mentén, hogy ha csak fényerőt, kontrasztot meg maszkelmosást akarsz finomítani, hamarabb rendereljen. Persze, ez is időbe telik, de nem annyiba. A kimeneti kép is ekkorára lesz méretezve. A renderbe kerülő nem.
Az alsó meg a keverési maszkok Gauss-elmosásának sugara képpontokban mérve, az esetleges átméretezés után, szóval ha a másikat állítod, ajánlott ezt is arányba hozni vele. Persze nem muszáj. Csak kicsit más lesz a kép kis meg nagy méretben ugyanakkora elmsási sugárnál. Volt egy olyan ötletem, hogy legyen ez is automatikusan beszorozva méretezési együtthatóval, de aztán mégse. Tessék csak külön állítgatni.
Az ez után jobbra lévő 3 bemeneti kép nodeba kell a 3 forrásképet betallózni, középre a "normált", fentre a sötétebbet, lentre a világosabbat. Igen, ez csak 3 képet tud összekeverni. Se többet, se kevesebbet.
Az a sok brightness/contrast node azért van minden maszknál, hogy szabályozni lehessen az egyes képekből bekerült részek méretét. Tweakelés közben opcionálisan viewer kapcsolandó rá, hogy lássuk, mi kerül a vegyesbe az adott képből.
A jobb szélső brightness/contrast meg már csak egy utolsó szépítés, hogy lehessen játszadozni vele, színezgetni, stb.
A jelenlegi egyetlen viewer a jobb szélén a backdrop miatt kell, meg azért mégis... Ha már a render képe olyan kicsi.
Ez alatt van a fájlkimenet, itt lehet kimeneti formátumot, tömörítést meg helyet/nevet állítani, ízlés szerint. Attól, hogy backdrop-ba kiszámolja a képet, még a rendesen, központilag is renderelni kell egy frame-et, hogy ez a node is lefusson. Mert anélkül nem fog. A scene-ben amúgy sincs semmi, csak egy kamera, mert az muszáj. A kompozitnak is csak azért van render-kimenete, mert az is muszáj. A render előtti átméretezést felőlem levehetitek, és akkor annak a rendernek a kimenete lesz a végső kép, nem a fájlba író node-é.
A képernyőképen látható betöltött eredeti fényképek a Wikipédiáról származnak.
Esetleges utómunkák, mint a gamma, meg egyéb görbék állítása, akár több kép utólag összekeverése is jó ötlet lehet.
Ez a módszer nem szép, nem jó, elvben működik, de nem is biztos, hogy HDR. A tone mapping meg szerintem egy végképp más dolog. Eljátszogatni, kísérletezgetni jó volt.
Ha valaki mégis ki tud hozni belőle valami használhatót, kérem szóljon.
Erre van egy olyan megoldás, hogy 3 (vagy 5 vagy 7 vagy 9) különböző expozícióbeállítással (EV) kell ugyanazt lefényképezni, és az alulexponált képből a világos részek fognak a kívánt képre kerülni, a túlexponáltból meg a sötétek. (Nem, nem fordítva.) Ami meg jó az automata érzékeléssel készültön, az maradhat úgy. Így tehát jó lesz a sötét meg a világos rész is, mintegy 3 kis "fényességsávból" 1 nagyobbat összevágva, majd összezsugorítva azt, hogy látszódjon a monitorokon. Persze auto bracketing nincs ebben a gépben, szóval autóversenyzésről nem fogok tudni ezzel ilyen képeket csinálni (Bár azt mondják, rawból elég egy kép is, és utólag lehet expozíciót állítani! :O Én nem tudom...), de tájakról még csak-csak. Állványom sincs, szóval majd leteszem az asztalra a gépet, vagy hozzáfogom egy faághoz. Nyers képeket nem tudok készíteni, tehát marad a JPG, ami már alapból csúnyácska, de színe még azért csak van valamilyen. Ezek csak az én problémáim, itt jön a lényeg:
Vannak direkt erre a célra kitalált programok, mint a Photomatix, vagy a Qtpfsgui. Photoshoppal, mint mindent, ezt is lehet. GIMPpel már annyira nem, mert azt mondják, az csak 8 bites képekkel dolgozik, és ennek 32 kell. Én ezt sem tudom, csak úgy olvastam. De azt tudom, hogy a CinePaint egy GIMP fork, amiben van 32 bites képfelbontás (úgy értem csatornánként), és néhány profi is használja. Csak nincs Windowsra, de az nekem mindegy.
A Photomatix drága, vagy próbaverziós, nem próbáltam ki. A Qtpfsguiban nekem első pillantásra sok volt a tekerentyű, huzogantyú meg választóka, és default beállításokkal nem volt jó (Programtervezési megjegyzés: Minden alkalmazásnál fontos a jól megválasztott default konfiguráció, hogy a kezdők, programmal épp csak ismerkedők egyből, mindenféle piszkálgatás nélkül használható outputot lássanak, még ha nem is tudják beállítani a programot, ami esetleg akkor már használható volna, ha jól lenne beállítva, de alapból nem jól van. Ha elsőre nagyon rosszat látnak, az baj.). GIMP-ben macerás meg időigényes volt egy-egy közbenső lépés finomítása, undo-redo, a maszkok beállítása, csatornákra bontás, visszakeverés, rétegezés, miegyéb. Ezen problémák kiküszöbölésére, és egy folytonosabb munkamódszer megteremtésére meg már csak a "csakazértis, mertmiértne" elv alapján, egészséges kíváncsiságból jutott eszembe, hogy a Blender tud node alapú kompozitálást. Tehát nem kell undozni, hanem minden változtatásnál újból lerendereli az egészet, és annyit meg tud a képeken bűvészkedni, ami nekem ehhez kellett. Maga a kompozitáló modul is tud fájlból több képet beolvasni, kiírni, meg menet közbeni képekbe is be lehet kukkantani. Egy szóval: tökjó.
Maga a módszer a maszkolásos keverésen alapszik, a maszkokat meg a képek fényereje szolgáltatja. Innen letölthető a .blend fájl. (Készült 2.57b verziójú Blenderrel.)
És így néz ki:
(Igen, kicsit "szellemes", mert a 3 kép nem pontosan fedi egymást, erre fényképezéskor figyelni kell. Az esetleges elő- vagyis inkább utóigazítást előre [Na, mégis "elő-"?] el kell végezni egy másik programmal. Mondjuk GIMPpel. Vagy ami jól esik.)
A bal oldalt lévő két számbemenet közül a felső egy korai relatív átméretezés mindkét tengely mentén, hogy ha csak fényerőt, kontrasztot meg maszkelmosást akarsz finomítani, hamarabb rendereljen. Persze, ez is időbe telik, de nem annyiba. A kimeneti kép is ekkorára lesz méretezve. A renderbe kerülő nem.
Az alsó meg a keverési maszkok Gauss-elmosásának sugara képpontokban mérve, az esetleges átméretezés után, szóval ha a másikat állítod, ajánlott ezt is arányba hozni vele. Persze nem muszáj. Csak kicsit más lesz a kép kis meg nagy méretben ugyanakkora elmsási sugárnál. Volt egy olyan ötletem, hogy legyen ez is automatikusan beszorozva méretezési együtthatóval, de aztán mégse. Tessék csak külön állítgatni.
Az ez után jobbra lévő 3 bemeneti kép nodeba kell a 3 forrásképet betallózni, középre a "normált", fentre a sötétebbet, lentre a világosabbat. Igen, ez csak 3 képet tud összekeverni. Se többet, se kevesebbet.
Az a sok brightness/contrast node azért van minden maszknál, hogy szabályozni lehessen az egyes képekből bekerült részek méretét. Tweakelés közben opcionálisan viewer kapcsolandó rá, hogy lássuk, mi kerül a vegyesbe az adott képből.
A jobb szélső brightness/contrast meg már csak egy utolsó szépítés, hogy lehessen játszadozni vele, színezgetni, stb.
A jelenlegi egyetlen viewer a jobb szélén a backdrop miatt kell, meg azért mégis... Ha már a render képe olyan kicsi.
Ez alatt van a fájlkimenet, itt lehet kimeneti formátumot, tömörítést meg helyet/nevet állítani, ízlés szerint. Attól, hogy backdrop-ba kiszámolja a képet, még a rendesen, központilag is renderelni kell egy frame-et, hogy ez a node is lefusson. Mert anélkül nem fog. A scene-ben amúgy sincs semmi, csak egy kamera, mert az muszáj. A kompozitnak is csak azért van render-kimenete, mert az is muszáj. A render előtti átméretezést felőlem levehetitek, és akkor annak a rendernek a kimenete lesz a végső kép, nem a fájlba író node-é.
A képernyőképen látható betöltött eredeti fényképek a Wikipédiáról származnak.
Esetleges utómunkák, mint a gamma, meg egyéb görbék állítása, akár több kép utólag összekeverése is jó ötlet lehet.
Ez a módszer nem szép, nem jó, elvben működik, de nem is biztos, hogy HDR. A tone mapping meg szerintem egy végképp más dolog. Eljátszogatni, kísérletezgetni jó volt.
Ha valaki mégis ki tud hozni belőle valami használhatót, kérem szóljon.
2011. máj. 28.
Váltás
Megszegve régi, önmagamnak tett fogadalmamat leváltottam az operációs rendszert a laptopomon.
Ubuntu volt rajta már pár éve, a sima kiadás, és mindig csak frissítve volt. A fogadalmam az volt vele kapcsolatban, hogy ha a végletekig tele is szemetelem, vagy félpercenként össze is omlik, szakítok azzal a rossz szokással, hogy "újrahúzzuk oszt' jólesz". Helyette szép kulturáltan kitakarítom, karban- és rendben tartom, vigyázok a rendszerre, és bármi áron helyreálítom, ha baj van.
Ez meg is volt, csakhogy egy idő után nem tetszett az Ubuntu. Az nem érdekelt, hogy "magasabb körökben" lenézik, hogy "titkárnő-Linux", az viszont már sokkal inkább érdekelt, hogy rohamosan elk**vult a rendszer. A Gnome Shell, a Unity, a Global Menu, a MeMenu, a rengeteg ilyen baromság nekem nagyon nem jött be. Eleinte, amikor bekerült a disztróba, a PulseAudioból is elegem volt. Néhány kiadás erejéig még ki tudtam gyomlálni, és sima ALSA-val zenélni, de aztán annyira beintegrálták, hogy rántott volna magával olyan dolgokat is, amik kellettek volna még, tehát maradt. Végül (nagyrészt) megszűntek a vele kapcsolatos problémák, és megláttam azt a néhány csekély előnyét a sima ALSA-val szemben, amik nélkül viszont igazán tudtam volna élni. Ezért lehetett tehát, hogy megbékéltem a mostani rendszerben is jelen levésével.
Ugyanis néhány hete az Ubuntu eltűnt a gépről, és jött helyette az LMDE, azaz Linux Mint Debian Edition. Gnome-mal, mert megszoktam. Azért nem sima Debian, mert a s**gnyalást is megszoktam. Külön tetszik, hogy rolling release, tehát nem kell szívni a félévenkénti dist-upgrade-del, elég a napi kis upgrade-ekkel... De azokkal akkor sincs annyi, és legalább egyesével jönnek. Lévén a Debian testing a forrásrepója, pár extrával, elég régi benne néhány (az összes?) csomag. Példának okáért a VLC, a GCC, és főleg a Chromium. Nekem pedig ezek kellenek, méghozzá új kell belőlük. (A testing-ben lévő Chromiumba még kiegészítőket [AdBlock Plus] se tudtam rakni a Store-ból, mert ahhoz is túl régi volt. Asszem 6-os körüli.)
Ezt úgy oldottam meg, hogy hozzáadtam a Debian unstable repóját is, és az apt preferences konfigfájlban "pineltem" olyan prioritással, hogy csak akkor rakjon fel belőle csomagot, ha azt én külön úgy kérem, de amik onnan vannak felrakva, azokat frissítse is onnan. Ez pedig a 200-as Pin-Priority. (Megj.: Az alapból jelen lévő 500-as priority-jű pinhez meg oda kellett még írni, hogy a=testing, mert anélkül mindre érvényes volt. [Asszem ez volt a külön szükséges változtatás]). Tehát jelenleg Gnome, Linux Mint, viszonylag stabil (testing) Debian, néhány "unstable" szoftverrel meg mentolízű extrával.
S látám, hogy ez jó.
Ubuntu volt rajta már pár éve, a sima kiadás, és mindig csak frissítve volt. A fogadalmam az volt vele kapcsolatban, hogy ha a végletekig tele is szemetelem, vagy félpercenként össze is omlik, szakítok azzal a rossz szokással, hogy "újrahúzzuk oszt' jólesz". Helyette szép kulturáltan kitakarítom, karban- és rendben tartom, vigyázok a rendszerre, és bármi áron helyreálítom, ha baj van.
Ez meg is volt, csakhogy egy idő után nem tetszett az Ubuntu. Az nem érdekelt, hogy "magasabb körökben" lenézik, hogy "titkárnő-Linux", az viszont már sokkal inkább érdekelt, hogy rohamosan elk**vult a rendszer. A Gnome Shell, a Unity, a Global Menu, a MeMenu, a rengeteg ilyen baromság nekem nagyon nem jött be. Eleinte, amikor bekerült a disztróba, a PulseAudioból is elegem volt. Néhány kiadás erejéig még ki tudtam gyomlálni, és sima ALSA-val zenélni, de aztán annyira beintegrálták, hogy rántott volna magával olyan dolgokat is, amik kellettek volna még, tehát maradt. Végül (nagyrészt) megszűntek a vele kapcsolatos problémák, és megláttam azt a néhány csekély előnyét a sima ALSA-val szemben, amik nélkül viszont igazán tudtam volna élni. Ezért lehetett tehát, hogy megbékéltem a mostani rendszerben is jelen levésével.
Ugyanis néhány hete az Ubuntu eltűnt a gépről, és jött helyette az LMDE, azaz Linux Mint Debian Edition. Gnome-mal, mert megszoktam. Azért nem sima Debian, mert a s**gnyalást is megszoktam. Külön tetszik, hogy rolling release, tehát nem kell szívni a félévenkénti dist-upgrade-del, elég a napi kis upgrade-ekkel... De azokkal akkor sincs annyi, és legalább egyesével jönnek. Lévén a Debian testing a forrásrepója, pár extrával, elég régi benne néhány (az összes?) csomag. Példának okáért a VLC, a GCC, és főleg a Chromium. Nekem pedig ezek kellenek, méghozzá új kell belőlük. (A testing-ben lévő Chromiumba még kiegészítőket [AdBlock Plus] se tudtam rakni a Store-ból, mert ahhoz is túl régi volt. Asszem 6-os körüli.)
Ezt úgy oldottam meg, hogy hozzáadtam a Debian unstable repóját is, és az apt preferences konfigfájlban "pineltem" olyan prioritással, hogy csak akkor rakjon fel belőle csomagot, ha azt én külön úgy kérem, de amik onnan vannak felrakva, azokat frissítse is onnan. Ez pedig a 200-as Pin-Priority. (Megj.: Az alapból jelen lévő 500-as priority-jű pinhez meg oda kellett még írni, hogy a=testing, mert anélkül mindre érvényes volt. [Asszem ez volt a külön szükséges változtatás]). Tehát jelenleg Gnome, Linux Mint, viszonylag stabil (testing) Debian, néhány "unstable" szoftverrel meg mentolízű extrával.
S látám, hogy ez jó.
2011. febr. 4.
Verziókezelő rendszerekről
Mivel egyre komolyabb projekteket kezdek (pl. most a szakdolgozatom), és már régebben is olvastam, hogy milyen jó dolog is ez, valamilyen verziókezelő rendszer keresésébe kezdtem.
Ebben is nehezítette a dolgomat, hogy "ökörh*gyoztában", vagyis 4-5 helyen is, 2-féle platformon fejlesztek mindenfélét, és csak a saját gépemen vannak kielégítő jogosultságaim és fejlesztői környezetem. Mindenhol máshol pendriveon IDE hurcolás+windows+mezei júzer.
Szóval ilyen rendszerekből van ugye kétféle: a központosított és az elosztott. Előbbiből a Subversion (svn), utóbbiból a git és a Mercurial (hg) jött szóba. Nekem már csak elvből is jobban tetszett az elosztott, meg saját (svn) szervert nem akarok mindenhol indítani csak ezért, a netet meg nem érem el mindig. Csak majdnem.
Maradt tehát a git és a hg. Az előbbi azért lenne jó, mert a "Nagyok" csinálták és használják, nyilván profi; de fele Perl, fele Shell, fele meg Linux-C, szóval windowson csak Cygwin-el vagy MSYS-el menne, amiből az utóbbi még csakcsak, de ha nem muszáj, azt se. Lévén a hg meg Python, az megy mindenhol. Megy pendrive-ról is (csak két sort kell átírni valami konfigfájlba, azt is a bugyuta meghajtókat-betűvel-jelölős, relatív-útvonalat-nem-ismerős rendszer miatt...)
Félig kizárásos alapon maradt tehát a Mercurial.
Online "backupként" pedig ahogy az svn-nek a SourceForge (jó, ez itt inkább A repó), a gitnek a github, úgy van a Mercurialnak is a BitBucket.
Elégedett vagyok vele, sokszor hasznos a revert, meg két év múlva jó lesz nevetni a changelogon...
Tanulság: DVCS-t a népnek!
Ui.: Hogy miért nem Bazaar (bzr) meg a Launchpad? Nem tudom, valahogy elkerülte a figyelmemet akkor. Elsőre nem találok benne kivetnivalót. Sőt. De már mindegy. Majd talán...
Ebben is nehezítette a dolgomat, hogy "ökörh*gyoztában", vagyis 4-5 helyen is, 2-féle platformon fejlesztek mindenfélét, és csak a saját gépemen vannak kielégítő jogosultságaim és fejlesztői környezetem. Mindenhol máshol pendriveon IDE hurcolás+windows+mezei júzer.
Szóval ilyen rendszerekből van ugye kétféle: a központosított és az elosztott. Előbbiből a Subversion (svn), utóbbiból a git és a Mercurial (hg) jött szóba. Nekem már csak elvből is jobban tetszett az elosztott, meg saját (svn) szervert nem akarok mindenhol indítani csak ezért, a netet meg nem érem el mindig. Csak majdnem.
Maradt tehát a git és a hg. Az előbbi azért lenne jó, mert a "Nagyok" csinálták és használják, nyilván profi; de fele Perl, fele Shell, fele meg Linux-C, szóval windowson csak Cygwin-el vagy MSYS-el menne, amiből az utóbbi még csakcsak, de ha nem muszáj, azt se. Lévén a hg meg Python, az megy mindenhol. Megy pendrive-ról is (csak két sort kell átírni valami konfigfájlba, azt is a bugyuta meghajtókat-betűvel-jelölős, relatív-útvonalat-nem-ismerős rendszer miatt...)
Félig kizárásos alapon maradt tehát a Mercurial.
Online "backupként" pedig ahogy az svn-nek a SourceForge (jó, ez itt inkább A repó), a gitnek a github, úgy van a Mercurialnak is a BitBucket.
Elégedett vagyok vele, sokszor hasznos a revert, meg két év múlva jó lesz nevetni a changelogon...
Tanulság: DVCS-t a népnek!
Ui.: Hogy miért nem Bazaar (bzr) meg a Launchpad? Nem tudom, valahogy elkerülte a figyelmemet akkor. Elsőre nem találok benne kivetnivalót. Sőt. De már mindegy. Majd talán...
2011. jan. 1.
[K|L|X]Ubuntu Live, CD nélkül
Nagyon jó dolog ez a Live CD-s kipróbálósdi, de egy hátránya van: lemezre kell írni a .iso-t, hogy betöltsön róla a gép. Vagy pendrive-ra rakni, vagy virtuális gépbe az .iso-t képként rakni.
Merevlemezen lévő .iso-t kiírás nélkül a natív gépre betölteni GRUB2-vel így lehet ni:
/etc/grub.d/40_custom fájlba egy ilyent kell írni:
menuentry "CD-kép a merevlemezről" {
insmod ext2
set root=(hd0,1) # ezen a partíción van a CD-kép
loopback loop /betoltendo/lemez/kep.iso
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=/betoltendo/lemez/kep.iso noeject noprompt --
initrd (loop)/casper/initrd.lz
}
Utána kell egy update-grub2 parancs rendszergazdaként, hogy újragenerálja a konfigfájlt.
Különben ennek meg olyan hátránya van, hogy azt a partíciót, amin a lemezkép van (amit GRUB-ban megadtunk rootnak), nem használhatja az így betöltött rendszer. Valamit valamiért.
Merevlemezen lévő .iso-t kiírás nélkül a natív gépre betölteni GRUB2-vel így lehet ni:
/etc/grub.d/40_custom fájlba egy ilyent kell írni:
menuentry "CD-kép a merevlemezről" {
insmod ext2
set root=(hd0,1) # ezen a partíción van a CD-kép
loopback loop /betoltendo/lemez/kep.iso
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=/betoltendo/lemez/kep.iso noeject noprompt --
initrd (loop)/casper/initrd.lz
}
Utána kell egy update-grub2 parancs rendszergazdaként, hogy újragenerálja a konfigfájlt.
Különben ennek meg olyan hátránya van, hogy azt a partíciót, amin a lemezkép van (amit GRUB-ban megadtunk rootnak), nem használhatja az így betöltött rendszer. Valamit valamiért.
Feliratkozás:
Bejegyzések (Atom)