Daniel, any news on your updated (automated) script?
2010/2/19, edgar.sol...@web.de <edgar.sol...@web.de>: >>> This reads to me only as not primary target. Not as in "we do not >>> support that". >> >> The point is that no developer will care whether OpenWrt runs on 2MB >> flash and no efforts are made to make sure that the system remains >> usable with only 2MB - I think this qualifies as "unsupported", it may >> work, if it does not you're on your own since it does not meet the >> specifications. > > Exactly my point. For binary images there is only a limited range of > devices supported. > >> Of course you're free to compile your own micro images with stuff left >> out but there won't be an officially supported binary release for 2MB >> flash devices. > > Well and this is what I can't call unsupported. Because when I come with > a problem on my micro router and there is somebody reading and > interested in the problem, I get support. If not, I don't.. there is no > difference to the binary builds. It is up to the people. And because > there is no company behind it people will only do what they want to when > they have got the time. > > Let's not tell people do not do this. But tell them. Try, if you dare ;) > >> >>> It simply states what was the case at the time of >>> writing. Also my understanding of the community project openwrt is not >>> to exlude anybody or some purpose. >> >> Not exclude something is not the same as actively supporting or working >> on it. > > and also not the same as unsupported. Unsupported means, we do not help > you with that. And that's not true. Or can you speak for all openwrt > contributors? ;) > >> >>> [extroot support split into lots of small packages] >> >> Imho for stuff like "blkid" the packaging overhead is higher than >> enabling the corresponding busybox applet - the package status info plus >> control file plus conditionals introduced elsewhere to check for the >> existance of a blkid executable is probably higher than the few hundred >> additional bytes of binary code introduced by enabling the busybox >> feature. >> >> I do not know whether we do ordinary users a favor by introducing dozens >> of microscopic packages just to allow some "power users" to get rid of a >> few features they don't want. >> >> I'd agree with an extroot-base and extroot-extra package maybe but not >> splitting each possibility out of the construct. > > well, How about one big additional storage package then? Additionally > enabling swapon and blkid from busybox? > This also makes it easier to maintain. There is enough stuff already in > base files. > >> In my opinion most users want a proven solution with a defined feature >> set that implements the current best practices. If somebody wants to > > Agreed. > >> implement external rootfs with the least amount of flash space he can >> select the tools he need manually and grab the script of the day from >> the wiki or some random blog. > > Only if he can disable the blownup/unfitting/readymade package before, > so that he has got the space and not lots of files cluttering his system. > >> I don't see why we can't just agree on some standard, say for example >> ext2 rootfs with ext2 fsck and blkid support. Whoever needs something >> else is free to create his own solution. > > That's a different topic. A default configuration for ext rootfs makes > absolute sense. > How would you expect the external media to be initialized (formatted)? > I am not sure it is a good idea to let the router do it during > firstboot. On the other hand image download users probably don't have a > linux around. > Also I think a journaled fs would make sense as most additional storage > might be loosely connected by usb. > >> This is much like the current firewall situation, many users use the >> firewall framework provided by OpenWrt and those who need more advanced >> stuff just leave out the uci firewall entirely and replace it with >> shorewall or custom made scripts. > > Not exactly. Every router will very very likely use firewalling. But > many routers simply do not have external storage interfaces and therefor > no use for anything regarding this. > Except of that, yes. > > Btw. thanks for closing the brcm-2.4 iptable issue eventually > > .. ede > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
