Posted 29 March 2011 - 02:40 AM
fox, you raise a very good and important point. I'm glad to see it mentioned now, early in Bodhi's lifetime, so it won't be picked to death for months on end. Follow my thinking for a couple of minutes.
My take on any additional scripting for installing additional software at installation is that the scripting wouldn't be coming out of thin air, but as Bodhi-specific additions to Ubiquity itself. It becomes just One More Thing to maintain. There would be the recompiling, bug-testing, etc. With so few "systems" people in Bodhi, it's one more task one of us familiar with Python (anybody other than me? anybody?) to take the time and become very familiar with Ubiquity's code. I've skimmed through that code and the many files and directories it contains. It is no less work than becoming a contributor and maintainer of a section of Pidgin, Evince, Rhythmbox or anything else. I shiver at the thought of maintaining such a Ubiquity fork. It takes time from important work. That's the one major point against any install-extras-at-install time.
What if the server is temporarily unavailable for some reason (or just the downloadable bods or the netinstalled applications)? That would make the entire install process look bad -- or at least "iffy." It happens to other distros who count on elements being pulled automagically from the net all the time. And does add time to the install process itself.That's a second point (and a half) against install-extras-at-install time.
What about the element of convenience? If you were installing Bodhi on multiple machines individually, whether at different locations, or on days independent of each other, wouldn't it save bandwidth & time as well as being more convenient to have the .bods on an external drive? Plug in from machine to machine, copy them to the machine immediately after setup and be done with it. Also convenient if you wanted to install application B but not application C on a specific machine. (I've done this very thing and using .bods on an external usb drive made it a cakewalk with the RCs.) Point three.
The user is going to be installing other software The Bodhi Way as more & more packages (applications, whatever you want to call them) are added to the Bodhi Software Center as time goes by. They may as well learn from The Beginning. It's a few moments longer than selecting an application by name only in a script. When installing from the software pages, the user receives a lot of information about the application in plain language, ultimately making for a more informed user if they even glance at the words on the page. At worst, they will have a memory of where to find some information about an application. I consider that knowledge a good thing. Point four.
Once each user has the same minimal system, they can take the time to see what is installed by default. Then consider what to install instead of doing it in an "I have to hurry and choose something" fashion. Point five.
An easy, fast, almost hands-off installation process. That's the ultimate in simplicity (and elegance)...the exact same installation experience for everyone before they make Bodhi into their own.
No distro I know does it that way. That's because (again), it's The Bodhi Way.
I ramble at length because I'm passionate about the Bodhi vision of elegance and minimalism.