nechci to až tak moc hanět - muselo to dát plno práce, ale stáhl jsem iso a spustil ve virtuálu. Asi to chce nějak moc paměti, takže ten základní předpoklad je asi úplně blbě :(.
Se 64MiB ani ťuk, tak jsem dal 128MiB a:
Initramfs unpacking failed: write error stali /bin/dmesg: write: No space left on device stali login:
teda prompt vypadl, ale asi to nebude plně funkční. Tak nějak nevím na co to je, když to srovnáme třeba s takovým TinyCore...
no schválně jsem si stáhl image TinyCoreLinuxu a to se vůbec nedá srovnat...
http://tinycorelinux.net/7.x/x86/release/
Nechápu jak to dokázali takhle nahňácat do tak málo RAM...
TinyCore a Core bez problémů na 64MiB a asi by šlo i méně (Core určitě). CorePlus chce více - tomu jsem dal 128MiB. Mají i image pro RPi jsem koukal.
hmm kdyz ten iso otevru 7-zipem tak ten stali.iso\ISOLINUX\INITRD.IMG\INITRD\ ma cca 45MB takze d o128MB ram by se vejit mohl, leda by kernel dal automaticky na initramfs nejaky (nizky) limit?
Hmm koukam na http://www.lightofdawn.org/blog/?viewDetailed=00128 kde dosli k tomuto " if you use "inittmpfs" (which is the default in modern kernels), your initramfs size is limited to 1/2 of 50% of your RAM, or 25% of your RAM. If you use "ramfs" by specifying "rootfstype=ramfs" in your kernel boot command line, when this limit can increase to 1/2 of your RAM (minus 0.5GB), or, about 40%-45% of your RAM "
Takze spis 256 RAM by to chtelo nebo nejakou kernel cmdline to zvednout.Treba pri mountovani tmpfs to taky da pulku ram jako default ale jde to zvednout -o size=x nebo tak nejak
Kazdopadne koukam na ty binarky uvnitr a nejsou nektere zas tak velike, ale treba ext2 utils typu mke2fs,tune2fs,resize2fs,e2fsck... ma kazda pul mega se svou kopii te same knihovny uvnitr. u veci typu X11 nebo Qt to uz muze byt docela maso pro kazdou jednotlivou binarku
tak squashfs se hlavne montuje z uloziste a nerozbaluje se do ram, narozdil od initrd(TinyCore i Stali pouziva pro initrd komprezi gzip..), TinyCore ma initrd 7MB(rozbalene 10MB), a Stali ma 36MB(rozbalene 46MB) a initrd nejdriv nahraje do RAM, pak vytvori rootfs (~tmpfs) "ramdisk" o 50% velikosti RAM kam ho jeste rozbali, z tech velikosti pak vychazi i ta vetsi narocnost na RAM...
jinak kdyz sem pred lety na ARM zarizeni s 32MB ram optimalizoval system, tak pouzit initrd v squashfs kompresi misto gzip melo slusnej vysledek v usetreni, pouziti squashfs modulu (ulozenych na sd karte) melo zas vyssi rychlost oproti nativnimu ext2fs na (totozne) sdkarte
!!!.
Není nad mrhání časem nad tvorbou noční můry z pohledu bezpečnosti... #facepalm
no právě. Zatímco Debian se snaží vystříhat nějakého staticky zalinkovaného kódu z důvodu bezpečnosti, v tomhle projektu to pojali opačně. Binárky budou ve finále větší v paměti to zabere více a další výhoda - rychlejší běh bez rekolovatelného kódu vezme taky za své, protože jako to bude velké - nevejde se tolik do cache CPU...
zatimco se Stali neni moznost napadeni pomoci LD_PRELOAD... ;)
http://www.root.cz/zpravicky/malware-napada-linuxove-webove-servery/
napr. http://blog.malwaremustdie.org/2014/06/recent-incident-report-of-linux-elf.html