On Sun, Jul 22, 2012 at 6:27 PM, David Given <d...@cowlark.com> wrote:
>> custom, minimal kernel, does a distro like SlugOS or OpenWRT offer >> advantages? I would assume their packages are meant to minimize >> RAM/Flash resources. > > It's been a while since I've done anything with them, but IIRC they're > based on the OpenEmbedded architecture. That has its own package > manager, ipkg, which combines some of the features of apt and dpkg. there is also a configuration option - i.e. some bitbake files - that can be included in a top-level file (or any sub-includes) which allows apt and dpkg to be deployed *instead* of ipkg. dpkg is, after all, just another bit of software that openembedded can download and deploy. > OpenEmbedded's big selling point is that it's a turnkey system which > will let you run a build with your own system with custom compilation > flags, and you end up with a custom kernel AND a root filesystem AND > custom builds of every package in it AND a set of ipkg feeds for > additional packages. > > But I've never actually made it work, so YMMV. i have, and once you get use to it it's f*****g amazing. its configureability, flexibility, comprehensiveness, number of platforms it supports as well as the number of distros it supports (kde, gnome, lxde, xfce, angstrom, opie, gpe being just a few) and the overwhelming way in which it can work out the full set of dependencies *including* right back to downloading the *source code* of the build toolchain - entirely automatically - is far FAR superior to anything that ANY other GNU/Linux distro has ever created, and that includes gentoo as well as debian. it's also absolutely superb for throwing in unusual or off-the-wall compile-time options that are not usually deployed; however it is smart enough to *stop* you from using options to compile certain packages for certain architectures that are known not to work, and also to add options and workarounds that are needed for particular OS-package-architecture combinations if you yourself left them out. translation: even if you picked a really weird and completely untested platform and a completely untested package combination that nobody else had tried before except for you, chances are that once you get used to openembedded it stands a good chance of working. compare this to debian where you are tied to a particular architecture with a fixed set of compiler options, but you want to try something different... well... good luck and let me know in a years' time how it goes! i mean... i don't know of any other build system which is capable of performing cross-compiles of packages by not just downloading a cross-compiler, oh no, that's been tried before and known to be problematic. so instead, it can be configured optionally to download a cross-compiler which is then used to compile a native compiler for the target platform, and then it uses qemu in headless mode to run that compiler and the configuration steps and the building of packages as if the compilation were occurring natively! compare and contrast this to debian having to force a rule whereby any distro's packages *must* be compiled natively on raw hardware (of the type of architecture for which the package is for) and you start to understand some of the power of openembedded. the only problem is: the sheer flexibility and scope of what openembedded can allow a small team of engineers to achieve over such a long period of time that openembedded has been going leaves it both drastically underestimated, underappreciated, and also quite hard to comprehend. the fact that python can be mixed with shell script in amongst bitbake commands, and the fact that appending an underscore and a suffix in lower-case to any variable, where the suffix is a meta-variable itself which can, if set, result in a configuration file in a subdirectory named after the meta-variable being pulled in and thus completely alter the entire build process, is just one of the features in bitbake that REALLY does peoples' heads in :) certainly i've been caught out by that before now. > http://www.openembedded.org/wiki/Main_Page > http://narcissus.angstrom-distribution.org/ > > It may also be worth looking at Debian's own embedded Linux project, > Emdebian, but I know even less about that than I do about OE. emdebian is primarily wookie's baby, and it involves cutting out bits of debian packages that you would not normally need on an embedded platform. such as documentation and so on. there are two variants, one of which is closely compatible with standard debian packages (called "grip" i think) and one which most definitely makes it harder to install standard debian packages (called "crush" or something like that) - i haven't looked at this stuff for a while. anyway i believe that the primary focus of emdebian "grip" is, as far as i can gather, to reduce the amount of disk space (NAND or other storage), whereas the additional focus of "crush" is to take that a bit further and also reduce the memory footprint. however, it may need someone like wookey or someone else that is experienced with emdebian to chime in and advise if it's suitable for use on platforms with 8, 16 or 32 mb of RAM. /peace l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDwOyDfrzVDw=g7=6o7OzJr0dSazYTEJbQvt=wbts+e...@mail.gmail.com
