I don't want weird bugs when I finally plug in my netbook to a IPv6 connection at some IT friend's house....<div><br></div><div>Optimizing bootup based on known, manufactured, fixed hardware is a great idea though. The hardware that's built into the machine should easily be enough to get you into a GUI. <div> <br></div><div>Initializing dynamic hw like USB drives and the network should wait until *after* booting though. There's no need to have my pluggable USB key ready before I can open a file manager or a shell to access it. </div> <div><br></div><div>Ultimately though, this is a pretty deep issue in the Linux configuration system. Time honored systems like /etc/fstab (fixed mount points for dynamic hardware? wtf!) and Xorg.conf (no pluggable input devices??) make this a real challenge. Udev is a step in the right direction, but takes like 10 seconds itself to start up.</div> <div><br></div><div>Perhaps the solution is something like this:</div><div><br></div><div>Write totally custom initscripts for XO which initialize all the manufactured hardware and launch into X. Once X signals that it's up, udev and NetworkManager are started to recognize all the dynamic stuff, do DHCP, etc.</div> <div><br></div><div>This could be accomplished by making an alternate '/etc/hwspec/xo-1/rc.d' tree which parallels /etc/rc.d and contains all the optimized initscripts. The 'init' program would detect the XO's hardware signature (presence of OFW seems typical), and then symlink /etc/hwpsec/xo-1/rc.d over the regular /etc/rc.d. If the hardware is unrecognized, /etc/hwspec/generic/rc.d is symlinked into /etc/rc.d and the generic initscripts are booted.</div> <div><br></div><div>This /etc/hwspec/... system could be packaged into its own RPM, so there would be no need to convince upstream to adopt all our optimizations into the generic initscripts.</div><div><br></div><div>Regards,</div> <div>Wade</div><div><br><div class="gmail_quote">On Wed, Mar 4, 2009 at 11:35 PM, <span dir="ltr"><<a href="mailto:pgf@laptop.org">pgf@laptop.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im">martin wrote:<br> > In fact, this might be something that upstream wants to think about in<br> > a generic sense. All the boot-in-5s focus lately is a lot of fun (and<br> > great for end-users, I surely want _my_ boxes to boot in 5s), but<br> > depends in part on skipping a lot of poking and waiting for hardware.<br> ><br> > Anyone building a custom Fedora for a netbook will want the same thing<br> > we want: a way to declare a "fast path" for known hw. Specially on the<br> > netbook segment this can have a huge payoff. (Wonder if Ubuntu doing<br> > something like this?)<br> <br> </div>i think the real win won't necessarily be declaring a fast path<br> for known hw, but _remembering_ a fast path for _any_ hardware.<br> i.e., if you've booted 10 times and never found ipv6, and always<br> found the same 3 filesystems in the same partitions, maybe it's<br> time to stop expecting anything else. does udev remember anything<br> from boot to boot? seems like it should if it doesn't.<br> <br> but as you say, there are also a lot of simple cases: most machines<br> have just one network interface, and it runs dhcp -- so once that<br> seems to be true, don't check for anything else. most machines<br> have one fixed disk, etc.<br> <div class="im"><br> paul<br> =---------------------<br> paul fox, <a href="mailto:pgf@laptop.org">pgf@laptop.org</a><br> _______________________________________________<br> </div><div><div></div><div class="h5">Sugar-devel mailing list<br> <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br> </div></div></blockquote></div><br></div></div>