There has been quite a lot of discussion of image creation, how many flavours there should be, where we store them and for how long, how they get generated and delivered etc. And there were many sessions at UDS as well as a couple of threads on this list covering this.
All this discussion left me feeling that people had got a little fixated on pre-generated images, and the alternative approach of using an installer has not received enough attention. Only the server sessions even mentioned this and even there we are still planning to start with an image and move to an installer later (IIRC). So I just thought I'd bring this up as a point to bear in mind as we move along. I really think we should be taking the installer option more seriously in the future, and not trying to serve the whole world of possibilities with images. There are clearly advantages to the 'just dd an image onto removable media and plug it in to get started' and having one of these available for that 'instant start' fix makes a lot of sense. I'm not suggesting we should stop doing that; this is the 'crack' to get new people addicted :-) But the more you get into having different images for different machines and purposes, the more you suffer from the combinatorial explosion problem. And all those images are actually just combinations of packages for the hardware and the software wanted, which are trivially specified and installed by a general-purpose installer (an example of which already exists in Debian, working across all architectures, using the same software to run the install as is ultimately installed on the machines). By using an installer (actually just a mini-distro image, which could be made exactly as the images we are currently making) running on the target hardware you gain the ability to make as many 'tasks' (currently images) as you like, and support as many boards as you want to support without the combinatorial explosion. And it can be skinned and pre-configured in different ways for different use-cases (fully automated/simple task selection/fully configurable, headless/gui, netboot/SD image and so on). I realise that this involves some work, but so does all that image-generation, and I do believe that the flexibility of this approach is powerful and we shouldn't ignore it to the degree we currently are. Pre-built images comes from an 'embedded systems' view of the world. Real computers can run installers to put their operating systems on and set themselves up, and we should be taking advantage of that. ARM computers _are_ real computers now and we should be treating them as such. Yes it takes a lot longer on initial boot, which is why I agree that there should be at least one 'instant gratification' image, but for real work, having to install your OS the first time you boot a board is not a big deal, and provides enormous flexibility. We can make it slick and painless. So, that's all. We don't necessarily need to have a big debate about this now, I'd really just like to make sure that this is properly on the agenda for the next cycle, and that we don't all get so stuck in the 'everything must be supplied as pre-generated image' mindset that we back ourselves into a very inefficient corner. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
