Healthy debate here, but what is really missing is someone from DEV to chime in and tell us what the real effort is to support these devices.
My point above was that I do not think that users coming from stock devices even know that memory plays a part in any of this, so why would they look for it. Most vendors do not include this spec.
When I try to find out if given router/ap is supported I go to supported hardware page.
This location should point out if there are any caveats such as limited functionality due to flash/ROM size, etc. I suggest to also make note which devices are most popular or most actively supported.
If 4/32 devices have support you can rest assured the customer service department will need additional staffing.
You can also be certain that 4/32 support will be dropped in the future...maybe as early as 18.01 ?
There will be no shortage of HELP!!! I can't install luci on my JUNK-13b.
Most readers of "For Developers" will not have much trouble making said JUNK-13b work OK.
But that type of user doesn't complain much either.
Even if JUNK-13b has absolutely no official support ... most of us could still build it ourselves and share if desired.
My point here is user satisfaction.
Typical end users will just NOT be happy unless their device has a web interface...and we will certainly hear ALL about it.
OpenWrt has a reputation as being difficult for beginners...I wonder why?
First you download ... then upload ... you upgrade ... then you ssh to 192.168.1.1
Huh? What you lost me there what is ssh how do I do that?
If you want gain happy NEW users ... LEDE will come with luci installed and WiFi enabled then still have space left over for luci-app-xyz.
That's not going to happen with 4MB Flash
Say Y here if you want to work in the complaint department.
Say N here if you are not interested in listening to numerous complaints.
As slh points out it is just a matter of time and 4MB Flash simply won't be enough ... same goes for 32MB RAM.
By the same logic, it's just a matter of time before 8M flash won't be enough,
same with 16M, 32M, etc.
you can't argue that some hardware spec won't be enough forever, so we should
abandon it now.
It's very reasonable to give a warning for 4M devices that we are currently
approaching the point where they can't run a 'standard build'. And for
individual systems it's fair to add a warning that they have hit it.
But if the codebase runs on them now, we should not be doing any work to remove
support from the codebase.
If the standard default config stops fitting on the
system, switch to a minimal config that builds enough to do a 'hello world' test
to make sure the hardware drivers work and flag it as 'experts only' from that
point.
When the 'hello world' build gets too big for a device, then it's time to
finally drop support for it, but that's a lot further off.
David Lang
I certainly agree the day will come when 8M and 16M are not enough.
However the days left for 4M seem to be nearing the end.
An experts only tag or something similar may be the way to go.
A "standard" build won't have nearly as many 4M devices if you include luci as it did say with a 3.0 kernel....
They'll be dropping dead soon enough anyway.
This discussion has significant overlap with the one about "unsupported devices" (stuff that is listed in ToH but is not truly fully supported), and imho it has the same solution, just add a "for experts only" tag and show a big fat warning to newbies.
The same tag can be used for devices that have wonky installation instructions (involving soldering or manual SPI flashing, and there are a few), or that aren't suited for newbies for other reasons.
Already there, on the very similar page:
I think it should be stated in all ToHs.
What other popular and flash / ram hungry packages are there that could be mentioned?
VPNs and any other package requiring encryption libraries, Samba (shared folders), 3G dongle support, filesystem drivers/tools for formatting and checking a filesystem for extroot.
4MiB devices can't fit anything noteworthy unless you use Imagebuilder (that requires a Linux system and some mild experience).
what is really missing is someone from DEV to chime in and tell us what the real effort is to support these devices.
I'm a half-dev (a "contributor"), I see the activity enough to report on this.
4 MiB device setups are already done (basically they disable some kernel options in these devices to shrink the kernel so there is more space to fit the rest of the firmware), and most of other stuff is shared with other devices with the same SoC (drivers, SoC-specific stuff, whatever) so it has to be done anyway.
The firmwares are built the same way, by the same tools used by all other devices.
I don't think there is any significant effort required to keep them supported.
There were talks about dropping support of some devices and it was not (directly) because of their flash sizes, but because they required specific hacks that are annoying to maintain, AND they were somewhat obsolete/rare AND they had low flash so they were not fun to work with.
Working on it.
As I suspected, so the impact is really CPU time and disk space for the buildbots.
Any thoughts on this?[quote="RangerZ, post:35, topic:1018"]
I do not know what the feasibility is of reworking the default images on these to include extroot configured for devices with 4mb and USB. Would this not go a long way to addressing the issue for both Trunk and Release? If I understand this, one pretty much would just need to plugin a properly formatted drive and go.
[/quote]
I do not know what the feasibility is of reworking the default images on these to include extroot configured for devices with 4mb and USB. Would this not go a long way to addressing the issue for both Trunk and Release? If I understand this, one pretty much would just need to plugin a properly formatted drive and go.
It should be easy to make extroot-ready images (as it's just a configuration for buildbots, "add package X, Y and Z, and they do this for luci in release builds), it would probably require some more logic in builders (so they don't build extroot images for devices lacking USB for example) though.
But I think this approach should not be followed.
I think the future of these devices (and LEDE firmwares in general) should be more towards using a web application that controls the imagebuilder tool, so everyone could make his own firmware with the packages he wants (on top of defaults) already integrated. As I already said in other places, integration of packages at build time or with imagebuilder places them in a highly-compressed partition which is much better use of the low storage space on most embedded devices. For 4MiB ones they won't fit much more than basic extroot setup OR luci OR VPN anyway, but for devices with 8 and 16 MiB it's a godsend.
So it would kill 3-4 birds with the same stone.
Freifunk (a german mesh wifi project using OpenWRT/LEDE) has already made one of such applications and it is open-sourced, so it should be just a matter of setting it up in a server or a Virtualbox "appliance" (a VM packaged for distribution) that people can use by connecting to a LEDE site or run on their PC with Virtualbox. See here http://lists.infradead.org/pipermail/lede-dev/2017-January/005050.html
Would be cool if there is someone that volunteers to do this, as otherwise I'll have to do it myself after i'm done with the Table of Packages in the wiki.
[quote="tmomas, post:47, topic:1018, full:true"]Working on it.[/quote]Looks good.
Where is stated that LEDE is going to drop support for 4/32 devices in 2018? Might be a good idea to link an official statement there.
I do not understand why adding extroot to trunk images is a bad approach. It's not either or. The naive user would need to do little more than connect a thumb drive and opkg update opkg install luci. They would also have the ability to store their version specific packages on the USB device, allowing them to extend the life of the trunk version (a feature useful to all devices running trunk actually). I understand that Luci may not be viable on top of this for say Release product in which case other decisions may need to be made.
The issue with any of the build tools is package selection, which requires a level of technical understanding that a new user can not be expected to have or may even wish to learn. They are still trying to grasp the basic concept of memory being a issue. Build tools are not for "Everyone".
I've come around to agree that 4mb support is feasible for anyone who understands LEDE and can build images. I can see a valid use for these devices for purpose built applications.
It's managing the new user we need to be concerned about who downloads an image file (trunk or release)
I do not understand why adding extroot to trunk images is a bad approach.
how many of these old devices that only have 4M have a USB port? I know it's
common now, but it wasn't always common.
The issue with any of the build tools is package selection, which requires a
level of technical understanding that a new user can not be expected to have
or may even wish to learn.
well, if they aren't going to select packages, they aren't going to need the
extra space either, right?
They are still trying to grasp the basic concept
of memory being a issue. Build tools are not for "Everyone".
how many people out there don't understand the concept of running out of
storage? Who is going to be installing LEDE who hasn't got a smartphone or DVR
that has rather limited space.
saying that people don't understand the concept of storage being an issue is
talking down a lot.
It's managing the new user we need to be concerned about who downloads an
image file (trunk or release)
The imagebuilder will have several presets to start from, so they aren't having
to figure everything out from scratch.
David Lang
I was just making that point to respond to your "Personally I would not want a Google search on "LEDE minimum requirements" to come up with >4MB flash and >32MB ram"
But we shouldn't worry about putting it in the wiki because they won't even search such things
UNLESS They actually do that sort of thing... its the same thing about search about hardware requirements for games but if they didn't search for it, the wiki will CLEARLY state the requirements when they browse the content of the website.
And just to note, these are requirements set so anyone who wants to install LEDE are able to do so without any problems. LEDE should "just work" All other cases are considered special" (If they do not have the hardware then that's an issue they have to solve, not LEDE)
There's no reason to say 4MB Flash supported compared to >4MB Flash supported. Why? well because we will have these kind of threads saying "I can't install Luci. I followed the instructions word for word and got this error... blah blah"
I do not understand why adding extroot to trunk images is a bad approach.
Because many older devices don't have USB or other storage ports, and because I personally think the imagebuilder web interface is much better than the current system of downloading a bare-bone firmware image and then installing packages with opkg for all devices.
Also because I don't want to pursue ways where I could get a "no" from a higher power.
With Freifunk's web interface I can make and distribute a virtualbox appliance for image building, and I don't need to ask jow or other core devs to go alter the build bots nor convince anyone.
Sure if they set up a server with that it would be cool (and jow already said that he was supportive for this), but a "no" would not be a deal breaker.
If you want to ask them to do that, you can always do it yourself, shoot a mail in the mailing list and see if you can convince them (mostly jow as he seems to be the one managing the buildbots).
The naive user would need to do little more than connect a thumb drive and opkg update opkg install luci.
Did you actually look at the current Freifunk firmware builder webpage? Users select profiles for functionality and specific configs, not packages or actual custom config files (sure there is the usual "expert users" panel where you can specify packages).
They would also have the ability to store their version specific packages on the USB device, allowing them to extend the life of the trunk version (a feature useful to all devices running trunk actually).
This is awkward, and the firmware builder page would solve that by simply allowing people to rebuild the firmware with all latest packages whenever they need, then you sysupgrade.
The issue with any of the build tools is package selection,
Solved by the usage of profiles in the web interface.
They are still trying to grasp the basic concept of memory being a issue. Build tools are not for "Everyone".
No, the main issue with build tools isn't that people can't grasp the concept of packages and finite space, but the fact that the current image builder only works on Linux and can only be controlled by command line.
I tried it, and watched the videos. It does not appear to work the way you imply. I can select some items for setting up the Wireless, LAN and WAN, but there is a packages section at the bottom. While packages are grouped by function there is no help to understand what combination of packges to select I want, or what any of them do. This in part is what I see as a gap in the table of packages. It just reguritates the poor descriptions in the packages.
What's needed are solutions. USB data device, for example which selects the core packages and then walks the user through what file systems they may want. Do you want the Web gui? It's what we call in my business a "rules based configurator" which validates the component selections are properly made. I have no clue what the dependencies are.
I don't see it. Profiles are devices, not solutions. So far that's like picking an image. Nothing here is "simple".
I have been implementing Enterprise business solutions for almost 30 years now. I know some users understand the concepts and even today can not hold a mouse. I know some are computer literate but lack the business understanding though they can push buttons in sequence. There is a spectrum of understanding that is miles away from what I, as the subject matter expert know. I know, painfully, that I need to tailor my work to suit their skills.
Unfortunately, I think you are overestimating your audience. I stand by my statement. Indeed, I don't think it ever occurred to me when I built my fist OpenWrt device that the firmware might not fit. It wasn't until I started to look at travel routers that I learned there were issues.
I think positioning image building, on line or not, as a solution is a problem, and believe many new users do not like it. While we have no statistics to back this up one way or another, I suspect that most people want to download firmware images, install and go. Once up and running they have little desire to upgrade until something breaks. My VPN server is CC 15.05 RC2 and will stay there. Those who use trunk are frequently surprised they can not add packages days or weeks later, but did so due the lack of a released version. I have no desire to invest the time to learn to build firmware. After 2 years I still feel this way.
I think the idea of being able to do this online is great, but it's far from user friendly.
4/32 warning in supported devices:
https://lede-project.org/supported_devices
4/32 warning in ToH:
https://lede-project.org/toh/start
4/32 warning in dataentries:
Where do you like the warning to be, top of the page or in the dataentry section?
https://lede-project.org/toh/hwdata/3com/3com_3crwer200-75
https://lede-project.org/toh/hwdata/3com/3com_3crwer100-75
The https://lede-project.org/meta/infobox/432_warning#details still need some refinement.
Please let me know your thoughts on all the above.
[quote="RangerZ, post:55, topic:1018, full:true"]I tried it, and watched the videos. It does not appear to work the way you imply.[/quote]The profiles with the device names also have a list of packages installed for them, it's not just a copycat of profiles from the imagebuilder.
With a different config file in the server you can have
DEVICE1-openvpn
DEVICE1-luci
and so on (names are just examples), they guy in the mail said that it's also possible to make profiles for packages to be added (used by some downstream projects), but I've yet to test the whole thing.
selects the core packages and then walks the user through what file systems they may want. Do you want the Web gui? It's what we call in my business a "rules based configurator" which validates the component selections are properly made.
That was my goal too. Plan B (if Freifunk does not allow me to do that easily), is making a bunch of PHP pages with buttons and dropdown menus, they assemble the package list and send the command to imagebuilder in the server, then gives a download link to download the firmware.
I have no clue what the dependencies are.
As said elsewhere, dependencies are handled automatically as each package states its own dependencies. If this does not happen, it's a bug in the package or the package was not supposed to installed like that (like for the ath10k firmwares that currently are not set up in a convenient way for USB dongles).
I have been implementing Enterprise business solutions for almost 30 years now.
As already said somewhere else, with LEDE we have the luxury of having a more IT-literate target than average corporate drone that goes completely bananas if you move the icons on the desktop.
The less-IT-literate users will never ever even think about changing the firmware on an embedded device. They don't usually even know what is a firmware. So you can safely ignore them.
Indeed, I don't think it ever occurred to me when I built my fist OpenWrt device that the firmware might not fit. It wasn't until I started to look at travel routers that I learned there were issues.
There are a bunch of normal routers too that have issues now. In LEDE they changed other stuff in the system (for good reasons) and all devices with 32MiB of RAM can't use opkg to install packages at all as it goes OOM (out of memory) even if there are like 10 MiB of RAM free, and that issue affects far more devices than just those with 4MiB of flash.
Modern travel routers have 8 or even 16 MiB of flash anyway.
I suspect that most people want to download firmware images, install and go.
Which is why a web configurator making a firmware ready to be flashed is better here, no need to use clunky luci package install interface or SSH in and use opkg to install stuff. (if it is possible at all, and in many older devices it is not)
I think the idea of being able to do this online is great, but it's far from user friendly.
It's just a matter of devising a decent UI for it. If Freifunk's does not provide something decent I'm either hacking it (if I actually can) or making a bunch of PHP pages.
I overlooked that question in my previous reply.
To answer your question:
End of LEDE support can be expected around 2018
I wanted to be more precise than "in the future", to make clear that it might already be relevant for todays decisions whether to buy a device or rather not.
However, "around 2018" is sufficiently vague to cover a broad range of time.
Looks nice, I think you should add that it's an upsteam issue not LEDE per se.
I think the above works well. It contains good language for novice or casual users and this same language, due to its wording, will be filtered by experience users. Works for me.