Hi Mike, >>So, to me the question is more along the lines of "is there somebody who >>is willing to work on making booting off something other than floppy and >>CDRom easier?" So far, the answer to that has been "no" (and there's >>only so much 5 or so people can do in their spare time). > > > Martin, > Do wisp-dist images provide a starting point for this goal? > > http://www.hazard.maks.net/wisp-dist/downloads/ > http://www.hazard.maks.net/wisp-dist/downloads/doc/c143.htm You're misunderstanding my question. I said "is there somebody who..." not "can somebody provide me with info so I can...". It could well be that the links you provided could help towards that goal - but _I_ won't have time to work on that before April. And as of then, I'll probably either be busy fighting off Spam from our lists or working on Bering uClibc 3.3 (or I might even be working on my social life - I know, unlikely, but who knows...) I'm still serious about my willingness to take care of our lists, by the way.
I don't know the ins and outs of wisp-disp. (I've never used it - back when it became part of LEAF, I had no use for WLAN, and when WLAN became relevant to me, I was more interested in getting it to work with Bering uClibc, so I never spent time looking at it), so it would probably take quite a bit of time to figure out how things work, and how that could apply to anything other than wisp-disp. >> > 2) It's insanely tedious to upgrade the software because the configs >> >>> are still stored with the binaries, and there are no tools for >>> merging diffs between the configs (e.g. ucf). >> >>Absolutely, no debate about that. This is something that has been on our >>todo-list for quite a while (and several people, including myself, have >>worked on it), but nothing mature enough to give to the public has come >>out of it yet (unless I missed something). > > > Vladimir has some form of unreadability incorporated into wisp-dist. It > might be worth evaluating. > > http://www.hazard.maks.net/wisp-dist/downloads/doc/c376.htm We're not that far yet - so far, the we (the Bering uclibc crew) still haven't decided wether an upgrade should simply replace the binaries (hence separating binaries from config would be a good idea) or wether an upgrade would also contain updating configs (important in cases where the the upgrade is needed to remove a security issue due to a problematic default configuration). There are valid reasons for either approach (the first is easy and could even be done automatically, but could break setups, in the cases where a new binary relies on additional settings in the config. The second seems "cleaner", but requires a lot more work, and has plenty potential of trashing the config on a given box). If it were as simple (at least, simple to us), we would have implemented it already. Martin ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
