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.
üzenetek
hozzászólások
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 ]
