Annó pont a raspberry pi kapcsán* hallottam a fedorásokról egy érdekes policy-t, hogy ők azon a hardveren fordítják, amin futtatni akarják.
*: indulásukkor egy fedora disztribúció armos változata lett volna a "hivatalos" rendszer, csak valami hibát nem tudtak sokáig kijavítani és nem jöttek ki vele.
Gondolkodtam rajta, hogy kellene egy olyan írás is. Még foglalkoznom kell vele előbb, hogy tudjam a pontos menetét 
Pár százezres (C) elektronikus kormány szervó firmware teljes fordítása kb 20 perc core i7-es gépeken. Pár milliós soros (C++) CT feldolgozó rendszerének teljes fordítása kb 2,5 óra szintén core i7-es gépeken. Akkor egy komolyabb oprendszer vajon meddig fordulna? Oké a kernelt, és a shellt lehet külön is, de az akkor is nagyon sok idő, vagy nagyon erős rendszer kell alá. Amúgy meg úgy sincs nálad a forráskód, így marad a linux fordítás, ha már ennyire szeretnél fordítani . Bármi le lehet fordítani házilag is, amihez van forráskódod, pl. linux kernel, gcc, make, akár ubuntu, notepad++, vlc stb...
(#14) azbest: Nem tudom amúgy, hogy az AVR CPU-nak mi a kód nevük, csak azt hogy Hardvard architektúrát alkalmaznak. De egyáltalán nem rossz, mert részben támogatva van a 16 bites műveletek (a CPU 8 bites), és teljesen statikus működésű.
Sejtettem, hogy valami hasonló lesz ok, hiszen ez lenne a legevidensebb, ha megoldható lenne, de rá kellett kérdeznem, hogy tudjam a miértet .
Pont havernak ezt mondogattam pár hónapja hogy valami automatizált módon biztosan meg lehet oldani hogy egy távoli gép csinálja a crosscompile fordítást a kis RPi-nek. Nagyon hasznos cikk
Én a Cubieboard-omat várom már hogy egyszer csak megérkezzen és játszhassak vele. Valószínűleg ahhoz is kelleni fog ilyen, mert bár jóval erősebb SoC és 1GB RAM-ja lesz, nem hiszem hogy nagyon elkapkodná majd.
Most épp azzal szórakozom hogy a gyári Android 4.0.4 image-t megpróbálom lefrodítani rá, szerencsétlen egy magos Atom-os lapomnak majd 12 óra mire végez a cross compile-al, de nem sietek egyelőre sehová 
Viszont rendszer image-t egyszerűen nem tudok gyártani, pedig elvileg a fordítás jól lemegy 
Nemtom, ennyire harmatosak lennének ezek?
A P3-as laposomon forgattam még csak saját kernelt, de az is megcsinálja kb. fél nap alatt.
Kormányszervó esetén laptopokról van szó csiga lassú HDD-vel.
Ne feledd, hogy kétszeres teljesítmény növekedésnél nem fele lesz fele a fordítási idő. A másik a fordítás szempontjából, hogy hogyan van felépítve a projekt, illetve milyen rule-jai vannak a make-nek, meg hogy C vagy C++ (utóbbi lassabban fordít). Na meg azóta a kernel is bővült pár sorral gondolom én.
A pi is megcsinálja 6 óra körül a kernelfordítást, viszont a teljes oprendszer esetén a rendszermagon kívül sok más program és azok libjei is kellenek. Azokat is lefordítva valószínű lehet egy több napos projekt ![;]](/dl/s/v1.gif)
és @buherton : Ez igaz... Csak az szúrt szemet, hogy az i7-en ennyire sok lenne.
Illetve, én örülnék neki, ha csak 2 óra lenne egy full kernel, bár nem fordítok ilyesmit mostanában.
Ácsi. Androidot is le lehet fordítani x86 alá? Ejhö, Cedar Trailes atomok örülhetnek
android-x86 , ettől függetlenül ő szerintem arm-osat fordít valószínűleg
Van ilyen projekt, de nem sok sikerrel... Nekem fizikai gépen el se indult.
Különben miért ne lehetne lefordítani Open Source dolgokat arra fordítod, amire akarod.
Lefordítani ugyan le lehet. De én most ARM-ra fordítok. A Cubieboard-ra készülök elő egy flash-elhető image-al.
Azok a gcc-k direkt arra a platformra keszulnek. AVR, ARM... Esetleg mar rogton ugy adjak, hogy valamilyen lib. keszlettel ossze is van csomagolva. En csak ilyeneket hasznalok. Illetve nem feltetlen gcc-t. Mert windows alatt a masok a lehetosegek. (De tegnap tobbszor is forditottam x86-on ARM-ra. Jo volt!)
Nagyon jo, es reszletes a cikked, nagyon tetszik! Kedvet kaptam kiprobalni... no, majd ha lesz idom... talan...
Szerintem teljesen felreertetted a dolgot, XP termeszetesen nem fordulna le ARM-ra, akkor se, ha lenne hozza forraskodod (amid nincs ), mert egyreszt tele van VisualC++ - specifikus cuccal (vagyis a gcc eleve meg se eszi a forrast), masreszt meg x86-specifikus cuccal (vagyis ha le is tudnad forditani, akkor se mukodne a vegeredmeny).
Kár... Gondolom ezért épül szinte miden opensource "nyitott" dolgokra (OpenGL, OpenCL, stb)
Amúgy egy telepítőlemezen rajta va a forráskód, nem?
"Amúgy egy telepítőlemezen rajta va a forráskód, nem?"
Nem, MS telepítőkön csak a telepítő van... A MS dolgok zárt forráskódúak, szóval a MS nem adja neked a forást. Vagy ha igen, hát az nagyon sokba kerül 
Az opensource dolgokat (Linux, meg még pár), kaphatod meg forrásban (annak rajta is van a telepítőjn sok részének a forrása, meg letöltheted), azt lefordíthatod magad.
[ Szerkesztve ]
Nem értem. Ha nincs forrás, akkor miből épül a szoftver? 
Hogyhogy miből?
A MS, meg a legtöbb szoftvergyártó esetében a lefordított programot kapod a telepítőn.
Opensource cuccoknál megkapod a lefordítottat, amit felteszel. Letöltheted, vagy kapod mellé a forrást is. Van, aminek csak a forrását szedheted le, és a gépeden lefordítod.
Pl. itt
A Source code-nál szedhetsz le forráskódot, azzal azt csinálsz, amit akarsz (át is írhatod)
A Binaries a lefordított, működő program (Linuxra is van, meg Windowsra is, meg még pár oprendszerre).
[ Szerkesztve ]
van forras: redmondban a pancelteremben. Jo, persze a naluk dolgoozo fejlesztoik is hozzafernek reszleteihez, meg nehany nagyobb orszag nemzetbiztonsagi hivatala is belenezhet. Oket pedig koti a titoktartasi szerzodes.
Te, mint vegfelhasznalo sosemfogsz talalkozni a windows forrasaval. Csak a keszre forditott rendszer telepitojet kapod meg. A licensz pedig megtiltja, hogy ebbol megprobald vissyafejteni a forras. Ha bizonyithatoan visszafejtettel belole, akkor beperelnek.
Erre van a Windows Embedded. ARM-ra is, nem csak x86-ra.
(Az egy masik kerdes, hogy mondjuk minek mindent tudni? Peldaul a Win forraskodjat...)
Ez egy jó kérdés. Az open source egyik tagadhatatlan előnye nyilván az hogy ha találsz valami hibát és értesz is hozzá akkor magad ki tudod javítani anélkül hogy a vendor-ra várnál és egyből vissza is tudod adni a közösségnek. Továbbá érdekes tud lenni egy ekkora rendszer forrását böngészgetni, lehet belőle tanulni.
[ Szerkesztve ]
Tehát rajta vana lemezen és, hameg van a kellő infrakstruktúra (ami nem egy Prescott P4) és a kellő bátorság meg minden hálózattól való teljes elszigetelés és a visszafejtő kulcs, akkor le lehet. Csak akkor se értelme, se haszna, se ajánlva a dolog.
Nem... nagyon nem.... a programozás nem így működik.
A lemezen gépi kódban található a program. Persze ez meghatározza egyértelműen a program futását / működését. Ma is programoznak még néhányan majdnem gépi kódban (assembly). De ez olyan, mint csepp a tengerben, nincs ember aki képes lenne átlátni a nagy egészet. A visszafejtés nem egy titkosított dokumentummal foglalkozik, amit ha feltörsz, akkor visszakapod az eredeti forráskódot. Valami kódot kapsz, ami azt csinálja, amit az eredeti forrás lefordított része csinált, de ember legyen a talpán aki meg tudja érteni vagy át tudja látni, ugyanis fordításkor teljesen átoptimalizálja a működést a fordító.
Szóval, ha érdekel a programok fordításának/visszafejtésének elmélete, akkor szánj rá néhány hetet és olvass utána a témának, mert az sokkal összetettebb, mint ahogy most hiszed.
Na ja. Azbest jól írja.
A forráskód visszafejtése kb. az, hogy a kész programot, ami le van fordítva, megpróbálod úgy elemezni, hogy a végén kb. megtudd, mit pötyögött be a programozó, aki írta. De ez nehéz.
Open source-oknál ugye megkapod, megkaphatod a forrást (sőt, általában kötelező kiadnod, ha saját progit írsz, és olyan licenc alatt terjeszted), és abba bele is piszkálhatsz, ha neked nem jó úgy.
De pl. ha saját magadnak fordítod, akkor megteheted, hogy a gépedre optimalizáltan fordítod. Pl. pont az mplayer a legjobb példa, megfelelően fordítva jobban kihasználja a hardvert->gyengépp hardveren is lehet vele filmet nézni.
Ellenben ha barki mokolhatja a kernelt, az nem tul biztonsagos.
Sajnos latjuk a Windows-zal is, hogy az mennyire biztonsagos....
Kivancsi vagyok, mikor robban ki valami linuxos botrany.
// Mert ugye ott biztonsag csak isten-bizny-ra van!
"Továbbá érdekes tud lenni egy ekkora rendszer forrását böngészgetni, lehet belőle tanulni."
Hat ez meg sosem tort ram... mondjuk szamomra egy driver erdekesebb tud lenni.
(Open source driverek meg vannak win ala is, fuggetlen attol, hogy eddig ilyet sem csinaltam)
[ Szerkesztve ]
"Ellenben ha barki mokolhatja a kernelt, az nem tul biztonsagos."
A dolgo ennel azert osszetettebb. A rendes kiadasokat nem bizergalhatja mindenki, amit meg az ember otthon mokol, az meg a sajat dolga.
"Kivancsi vagyok, mikor robban ki valami linuxos botrany.
// Mert ugye ott biztonsag csak isten-bizny-ra van!"
Mert mashol mire?
Tenyleg, ha az alapokkal se vagy tisztaban, akkor inkabb kerdezz, ne beszelj ilyen szamarsagokat.
Szerintem többen vannak, akik szeretnék ha a kernel minél biztonságosabb lenne, és tesznek is ezért, mint amennyien kiakarják használni a sebezhetőségét. Amúgy meg nincs tökéletes rendszer.
[ Szerkesztve ]
A windózét senki se mókolhatja, mégis tele van buggal.
Tehát ebből a szempontból irreleváns.
Sőt, ha valamit nem biztonságosnak ítélsz meg, kiszórhatod a kernelből.
"Kivancsi vagyok, mikor robban ki valami linuxos botrany."
Úgymint? Biztonsági rések vabbak, szokták foltozni, ennyi. Ez minden rendszeren ilyen.
Mondjuk a múltkori Java bug meredekebb volt
[ Szerkesztve ]
Igen, ez egy erdekes megkozelites... Arra jottem ra az elmult par ev alatt, hogy senki nem tudott ez iranyu kerdeseimre megnyugtato valaszokat adni. Az pedig egy eleg fura helyzet, ha mediafire, meg istentudja honnan letoltott modulokat forditok be a rendszerembe, hogy megfeleloen mukodjon. Nekem egy alapitvany biztonsagi szabalyzata nem nyujt biztonsagerzetet.
Ha egy nagyobb gyarto ( TI, Freescale, ST) oldalarol toltom le, az meg csak-csak rendben van / ad nemi biztonsagerzetet. Meg ha csak latszolagos is.
Regen, amikor letoltottem valamit a "http://sourceforge.net/"-rol, megcsinaltam, amit kell, bepattintottam a kis nyolcbitest a foglalatba, oszt jovan.
De mostanaban olyan dolgokkal maszatolunk, (en is,) hogy as'se tudjuk, mi az eredeti forras, hany kezen ment at.
Persze, igazad van, nem ismerem az alapokat sem, nincsenek szamitastechnikai tanulmanyaim, nem is tudok mast, mint egy par 10 oldalas getting started guide alapjan android kernelt forditani... meg guglizni... de vajon hanyan lehetnek meg igy ezzel!..
Szokás erre mondani, hogy saját felelősségre... Ha nem bízol benne, nem használod.
Azért egy Linuxos PPA rendszer sokkal biztonságosabb, illetve a fejlesztők oldalai is.
És persze MS oldalon sem tudod, hogy a KB47384354 frissítés mit csinál valójában...
[ Szerkesztve ]
Az akartam mondani, PC-s hasonlatnal maradva, hogy nem tudom, mit csinal a KB47384354, de a gyartotol jon. Sot, ha veszek valami alkatreszt a gepbe, annak a drivere is vagy MS, vagy az alkatresz gyarto drivere. Egy Linux disztronal meg sokszor 0 a support, valahonnan, forumrol talalok megoldast, amit valahonnan letoltok. Androidnal is jartam mar hasonloan. Es en ez utobbitol rosszabbul alszok. Haver meg szemrebbenes nelkul bele tolt ilyet kartyapc-be, ami utana felkerul egy ceg halozatara, csatlakozik a vallalatiranyitasi rendszerre... no mind1, ez mar nagyon OFF!..
[ Szerkesztve ]
Aha. És a gyártó mitől megbízható? Főleg a MS... Illetve volt már olyan vírus, ami frissítésnek álcázta magát, ha jól emlékszem.
Illetve, hogy a driver support MS-re, pl. a Creative hangkártyáké? A Leadtek tunereké...?
Különben az ilyen "nem megbízható" források kezelésére szokás tesztrendszert tartani.
Jobb helyeken még a frissítéseket is csak egy tesztrendszerre engedik rá, utána megy ki az éles hálóra.
most nézem, hogy az alternatives mókolás helyett, ha betesszük a path elejére a
/usr/lib/icecc/bin
mappát, akkor már eleve megvan az a symlinkelés amit az altenatives megcsinál, talán az még egy fokkal jobb megoldás.
tehát mondjuk a .bashrc végére
export PATH=/usr/lib/icecc/bin:$PATH
játszottam kicsit a raspi2-vel is ezen a téren...
kiderült, hogy ubuntu alatt egész könnyen lehet cross-toolchaint készíteni, mert van erre csomagjuk.
sudp apt-get install gcc-4.7-arm-linux-gnueabihf-* g++-4.7-arm-linux-gnueabihf
/usr/lib/icecc/icecc-create-env --gcc /usr/bin/arm-linux-gnueabihf-gcc-4.7 /usr/bin/arm-linux-gnueabihf-g++-4.7
és ezt elég csak átmásolni a pi-re. Persze a pi-n is 4.7-esre kell váltani a gcc g++ verziókat.
Lehet 4.8-at is érdemes kipróbálnom.
Viszont feltűnt egy komoly szűk keresztmetszet a pi-n. A preprocesszor cc1 a pi-n kell, hogy fusson, ez készíti el a bemenetet a fordító számára. És bizony a 4 magos pi-nél az aktuális kernel modulok fordításakor nem lehet fél óra alá menni, mert a cc1-ekre kell várni és nem tudja etetni a farmban lévő fordító gépeket.
Szóval ez tényleg arra jó, hogy a pi-n direktben menő fordítás sebességét megdobjuk, de ha igazán gyorsan kell fordítani, akkor ahhoz valami chroot-ba kell tenni a raspbian fájlrendszert és a pécén futtatni a cross-toolchain-nel és icecc-vel a fordítást. A pécé elég keményen oda tud lépni a preprocesszáláshoz, hogy kihajtsa a farm fordító gépeit. Aztán az eredményt lehet a pi-re visszatolni.
Úgy emlékszem olyan megoldást is láttam valahol, hogy a board-on lévő fájlrendszert csatolták fel távolról a pécére, úgy gyakorlatilag oda is kerül a helyére az eredmény fordítás közben a pécéről.
Nokia N9-hez volt olyan környezet, ami a teljes platform fájlrendszerét tartalmazta, az armos dolgokat qemu-val futtatta, de a natív cross-toolchain is futott benne. Icecc-t is be lehetett lőni alá...
[ Szerkesztve ]
