Először is kell 8 db fakocka. A méret tetszőleges, én 25 mm nagyságút használtam. Ezt fogom
beborítani kívül-belül képekkel. Egész pontosan 3 db nagy kép és 6 db kis kép kell. A nagy képet úgy
kell elképzelni, hogy 4 x 2 kocka (ill. kockának egy lapja) nagyságú, a kicsi meg 2 x 2. Ez azért
praktikus így, mert 1 kockára való képet össze lehet tenni pont egy A4-es lapra amit ki lehet
nyomtatni fóliára. A módszer nem tökéletes, mivel erről a fóliáról könnyen kopik a festék, így
papír-írószer boltban kapható széles celluxszal (az a nagy, 5 cm szeles) le kell ragasztani a fóliát
felülről is. A Copy General 500 DPI-s nyomtatót használ, tehát egy kockalapra való képet 1100 px
szélesre érdemes készíteni.
Az A4-es képet kézzel is el lehet készíteni, meg egy scripttel is -- de ez utóbbiról később. Ha
kézzel akarjuk akkor így érdemes elrendezni:
1
Ha scripttel, akkor egy enkockam könyvtárban lesz 4es meg 8as nevű alkönyvtár és abba kerül a
3 db 8-as és 6 db 4-es kép. ezután kell a kocka.py:
$./kocka.pyenkockam
Ez elkészíti az enkockam.jpg file-t.
A következő kérdés, hogy ezeket a nagy és kis képeket hogyan érdemes felvágni. Ha túl sok vagy kevés
vágás lesz, akkor vagy nem lehet körbeforgatni a kockát, vagy szétesik a kocka. Színezem a képeket,
hogy ne kavarodjanak össze.
Nézzük először a nagyobb képeket, sötétkék, világossárga és sötétzöld:
2
A kis képek vágása: piros, narancs, sárga, világoszöld, világoskék, krémsárga:
3
A kocka 6 lépésben körbeforog. Felragasztás: A 8 db kis kockát négyzetekbe rendezzük, és egymásra
helyezzük. Tegyük fel a tetejére a narancsot, úgy felvágva, ahogy a rajzon látható. Húzzuk le a
hátáról a fóliának a külső rétegét és ragasszuk is rá. Előttünk lesz a krémsárga oldal (szintén a
rajzon látható módon, tehát a vágás vízszintesen van), balra a piros, jobbra a sárga (a vágás
függőlegesen legyen, a rajzhoz képest 90 fok forgatással), hátul a kék (a vágás vízszintesen
legyen), alul pedig a világoszöld (rajzhoz képest 180 fok forgatás, ugyanúgy jobbra lesz a kis rövid
vágás mint a tetején a narancsnál).
Ha idáig eljutottunk, akkor (felülnézetből) a jobb alsó és a jobb felső hasábját ki lehet hajtogatni
a kockának. (felülnézetből egy 4 kocka magas narancssárga csíkot kapunk). Jobboldalt az egész nagy
felületet elfoglalja a sötétkék. Már csak a sötétzöld és a világossárga maradt. Forgassuk el balra
hossztengely szerint a nagy kockát, Tehát felfele fog nézni a nagy kék felület. Most nyissuk szét a
nagy kockát úgy, hogy hosszába a bal felét balra, jobb felét jobbra forgatjuk 90 fokkal. Továbbra is
téglatest lesz előttünk, de most már a kék rész jobb és baloldalon függőlegesen lesz, és nem
borított rész tárul elénk. Ide kell a világossárga.
Már csak a sötétzöld maradt. A cél, hogy ez kívülre kerüljön. Menjünk vissza két lépést, amikor a
kocka még egyben volt: összecsuk, újra kék lesz felül, forgat jobbra 90 fokot, narancs csík lesz
felül, alul-felül összeforgat úgy, hogy kocka legyen újra. Most áthajtjuk a kocka felső felét jobbra
úgy, hogy újra téglatestet kapjunk. A világossárgát fogjuk látni megint, és bal- meg jobboldalt a
szélén pedig a kettészedett pirosat. Elforgatjuk az asztallapon a kockát 90 fokkal. Ugyanúgy ki
fogjuk nyitni, mint mikor kékből sárgába mentünk át, csak most a sárgából csupasz lap lesz, és erre
a 8 kockalapra fog kerülni a sötétzöld.
Frissítés: 2025-ben ezt a leírást követve úgy tűnik, hogy az utolsó kettő sorrendje fordított kell,
hogy legyen, tehát sötétzöld az utolsó előtti és a világossárga az utolsó.
Frissítés 2: újra követve a leírást úgy tűnik, hogy az utolsó kettő vágásának egyeznie kell, tehát a
sötétzöld szerint kell felvágni a világossárgát is.
and we're ready, you'll have a daily updated git import.
one minor note: the bitlbee.git dir is a non-bare repo and it's also a bzr repo which is not a problem (you can clone it and gitweb handles it) but if you plan to switch to git later, you probably want to clone it once get rid of that junk :)
..continuing last year's article. so another year passed by and it's time to look back and see what we did during 2007. probably i miss a lot of stuff but here is my list:
1) ability to go back in the installer to a previous point if you missed something. do you remember the days when one had to reboot if he/she wanted to do so? :)
2) compiz improvements. this is now settled down in current and it's pretty sane. we cleaned up the old compiz and beryl, we have a single compiz-fusion, it has a nice step by step documentation and it works fine both for kde and gnome.
3) asciidoc. i think we highly improved our documentation since we switched from latex to asciidoc. a user manual of 98 pages in a nice pdf format is cute, isn't it? :)
4) newsletters. Alex started to issue newsletters and recently phayz helped out us, so it's alive again. i think it's something great.
5) yugo. 'factory' was our previous i686 build server, it was a very old machine with a cpu of 300mhz and so on. it was time to replace it and now yugo does the job.
6) fwlive. this was an old project but only test versions were available, based on old frugalware versions. now there is a live version of every released version of frugalware, thanks to janny, boobaa and ironiq. great!
7) gnetconfig. the first graphical config tool from priyank. i'm really bad at any graphical programming, so i'm glad to see finally we started to work on guis.
8) gfpm. something users always wanted and now it's here. a true graphical package manager, which is not just a wrapper but properly uses libpacman. awesome.
9) fun. this is our update manager which can sit on the system tray (or whatever i should call kicker not to be kde specific ;) ) and notifies you if there is something to update. i'm sure this is more comfortable compared to watching the -security mailing list for updates or doing a -Syu daily :)
10) syncpkgd2. if you remember, the old method was that there were only clients and they tried to figure out what to build, they built and uploaded the packages. this was very suboptimal: it allowed only one buildserver / arch and it was slow. okay, being slow is the smaller problem, but every buildserver was a single point of failure. nowadays we have two i686 buildservers (thanks to boobaa) and it's theoretically it's possible to have two x86_64 buildservers, too. so even if one i686 buildserver is down, i can be at the beach, sipping a mojito :)
you have a client behind a firewall and you have a server somewhere. and you want to ssh from the server to the client. that's exactly why ssh has a magic -R option!
if you do an
$ ssh -R 19022:localhost:22 server
that will mean that you can ssh to client:22 on the server by sshing to localhost:19022 on the server. yes, and it works even if the client is behind a firewall, yay! :)
update:
you probably want to add this to your ~/.ssh/config on the server as well:
Host client
NoHostAuthenticationForLocalhost yes
HostName localhost
Port 19022
git-svnimport will be removed in git-1.5.4 and i don't think it's tirival to use git-svn (which is great for bi-directional work) to properly convert an svn repo (with multiple branches) to a git one, so here is a recipe.
first, just use git-svn to create a git-svn repo. it's a git repo but it's a bit weird, it contains metadata which is necessary for bi-directional operations and you won't see the branches by default when you clone it. ah and it's not a bare repo.
in this example i'll convert ooo-build's svn repo (it has several branches and tags, so it's a good example).
of course this is an incremental operation, so all you need is to run git svn fetch and git fetch from cron to keep the mirror up to date.
update:
it turns out you can even do this by having only one git repo. it has benefints: you don't have to duplicate the object database. and it has one problem: if you later switch fully to git, then you want to remove the git-svn metadata - doing so is the easiest if you just clone the repo.
note: git config --add remote.origin.fetch +refs/remotes/trunk:refs/heads/master it unnecessary as git svn fetch will update this for you (it is different from git fetch)
thanks for devurandom from #git for pointing out that this is possible using git --bare init before git svn init and using git --bare svn fetch :)
