[I'm tagging this note as a Decision Panel message since I think it's relevant to why I think Sugar Labs should at a minimum do its own Linux distribution variant. If SL is going to promote Sugar to the masses via a live USB images we need to be in a position to work directly on the kinds of problems/issues that I discuss below. I say this because I don't think any other Linux distribution will have the NEED to make it work for everyone as badly as we will. If we are willing to let the Linux distributions decide for us in what hardware environments Sugar will run easily/well then it is less critical.
To be fair promoting running Sugar under virtualization might be a partial solution as well. We would essentially push all of the hardware compatibility issues to the Microsoft Windows drivers that came with the machine. I see several downsides: 1. Any cost arguments about not needing Windows licenses or lower spec machines go out the window. 2. Camera and microphone access from within virtualization products seems to be problematic. Any activities that depend on this go out the window as well. 3. I'm not yet sure if there is a good way to continue to allow the user's data let alone their activities to be stored on removable media.] On Tue, Sep 29, 2009 at 1:10 AM, Martin Dengler <[email protected]> wrote: >> >> >> >> 1. They are designed to auto discover/configure their hardware/network >> >> access at every boot. >> > >> > So is every modern major linux distro's default install. >> >> Sure they all try to do their best at auto discovery WHEN you install >> them. To a greater or lesser extent, they then hard code >> the results of that discovery process. A truly portable/transportable >> (i.e. live) system can NOT ever do this. Nor can its developers rely >> on users doing manual configuration for the myriad corner cases. > > Hmm...the F12 images I'm familiar with do none of this. The only > "hard coding" is the installed device's UID, which is the same as > would be for a non-removable drive. The rpm selection isn't > customised by hardware at install time (except manually on requst, > again as would normally be done by a person installing things). Sorry I'm not thinking about rpm selection. I'm thinking about getting the broken/inconsistent PC hardware platform to actually work. All the crap which still requires people to carefully investigate PC hardware for Linux compatibility before they buy it rather then just walking into a store and buying which ever color 'PC' strikes their fancy. Even knowing the chips isn't always sufficient if the hardware vendor has strayed too far from the reference design they got from the chip manufacturer. This is where manual configuration comes into play. Kernel module options and the like. If I'm sufficiently guru I can track this all down and set things up for my personal computer. I'm not going to do this for every random machine that my library, school, employer, relatives might own. And I'm certainly not going to suggest that an overworked teacher or a just learning to read eight year old do so just so they can work on whatever computer they might have acquired for home use. > Otherwise it would be really hard to create a live image using a given > machine that was useful on different machines (which is what happens). F12 Alpha Live won't boot on my primary test machine. F11 did but KMS seems to have broken my machine. Even when I try the recommended boot time options to turn it off, it still doesn't work. Even if it had worked, it would have been one of those manual corner cases that I mentioned. Fine for an installation that is only going to run against a single hardware configuration. Not so good in a portable environment. I have a donated lapop that won't boot from a USB stick and can't use the current Strawberry CD boot helper. It will boot from some Linux boot CDs just not from the Strawberrry ISO. I'm pretty sure that this is because BIOS only supports 'floppy emulation' booting and the modern way to make a bootable Linux CD is to use isolinux with no emulation mode. My reading of the syslinux/isolinux site/mailing list is that this was (and may still be) a limitation in BIOS. If Windows doesn't use a feature of a standard then it probably doesn't work in half the machines which are first shipped to that standard. OTOH, any machine that supports the 'no emulation' booting probably does the full standard. > > The same hardware drivers are installed at install time for a "live" > install as for a non-live, subject to the "live" image creator's whim. > For example, check the SoaS package list at > http://people.sugarlabs.org/~mtd - 43 xorg-x11-drv rpms for hardware That url gives me a blank page. > not at all related to the live installation. Bloated, yes. The same > as non-"live", also yes. > >> Unfortunately, it seems like most of the current live systems just >> re-run the standard auto discovery software at every boot and hope for >> the best. > > No - ibid. If I haven't responded to this in the rpm vs. hardware issues above, let me know. > >> If sound doesn't work it's not that big a deal. > > sound autodetection is not related to removable / non-removable > installation media. Not directly no which is why I placed this underneath the auto discovery section of my response for that reason. As I see it there is a synergy going on here. Good auto discovery/configuration of hardware allows for the possibility of booting and running from portable media. Better portable media (faster/higher capacity/writable/cheaper/smaller) increases the number of use cases where using portable media is a good fit. In the case of Sugar, cheap bootable USB sticks has the potential to continue to some extent the 1-1 model (one user per hardware device) model that the XO-1 promoted; but at much lower direct costs (An underlying assumption that computers are somewhat common makes this not relevant in the poorest parts of the world.) >> Unaccelerated graphics is fine since I'm not really going to use >> that environment for long. > > With X autodetection and all the free drivers (as above), this is not > a difference between live and non-live images, either. And when it fails (and I've yet to see an autodetection that doesn't fail somewhere) we'll just have a HOWTO somewhere to tell you what to do after you install the system in text mode to the internal hard drive. Not the model of use that I was hoping for. > >> >> 2. They are designed to run from what is usually thought of as >> >> removable media (this is either a result of or the reason for #1) >> > >> > How so? /etc/init.d/livesys* is all I can think of, and that's not >> > necessary these days. >> >> A default Fedora install (as compared to a Live USB/CD) doesn't use >> the same filesystems. > > The partition layout is specific to the installation medium (as > always), but apart from that (which could/would be different, say, > between a 2G USB stick and a 8 GB SD card), I don't see how that's any > different than a 30G SSD or a 120 GB HD. squashfs? using dm overlays? I suppose dm isn't a filesystem. Bill Bogstad _______________________________________________ SoaS mailing list [email protected] http://lists.sugarlabs.org/listinfo/soas
