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
