So here's the deal. LEDE is very limited in terms of developers hence there's
not an option or value to deviate too much from upstream whether we like it or
not unless we want to create some strange fork that's going to be a pain to
maintain. The Linux kernel is growing, so are stock libs and applications.
Work is being done to slim these down by default but again, no one is going to
rewrite half of the distro's software and there's little to no interest
upstream so maintain 8y+ (usually) old devices while adding new ones. There's
just too much overhead, code-rot etc by doing so which more or less translates
into that "everything" has to fit the new "way"/code. Also, having the above
in mind we want upstream support when it comes to kernel/software etc, there's
not enough manpower to reinvent the wheel and having support for a lot of
custom software is a pain.
Nobody here is disagreeing with the above statements.
If the software grows too big to run then the device can't be supported any
longer.
What we are objecting to is the rush by some people to abandon/delete support
for devices.
There are always options to consider, smaller/lighter versions of software to
consider using, ways to NOT use some software.
As a couple of examples LEDE does not use glibc or systemd, in large part
because of the size of those packages. According to some people in the Linux
world, those would not be reasonable options to consider and any hardware that
wasn't big enough to run them isn't big enough to support at all.
But in some cases, we do need to look at tweaking/re-writing software. For
example, if opkg is unable to run on 32M ram, even if 10M ram is available, then
it's probably appropriate to find out why and figure out other ways to get the
job done. My uninformed guess is that opkg does something along the lines of
enumerating possible packages in ram, and as the list of supported packages
grows, it eats more and more ram. Options like mmapped files or using disk files
instead of ram are options if this is the case.
Nobody is objecting to dropping support for devices when they can't be loaded
with a minimum build, and nobody is objecting to dropping pre-built images for
systems when the standard image will no longer fit.
We are objecting to the idea that "someday it won't fit, so let's drop support
now".
We are trying to suggest a path for graceful degredation of support over time.
Personally, I see support as a continum, something along the lines of
-
best support, able to run the standard image and load significant amount of
additional packages -
limited support, able to run the standard image, but not able to load much in
the say of additional packages. -
minimal support, no longer able to run the standard image, but able to run a
"hello world" minimal image, so still useful for people doing customized things.
it seems as if the 4/32 routers are in category 2 right now. The imagebuilder
tool seems to be the key to making good use of these devices.
But for those saying that we should abandon support for everything that can't
run LUCI + Samba, etc. I'll point out that the project is "Linux Embedded
Development Environment", not "Linux Access Point OS". The project is intended
to support devices beyond just APs. As long as the hardware is able to boot a
minimalist build, someone can make use of it.
David Lang