I think the de-bricking ease should be a factor as well (and probably possibility to revert to stock). Because bricking happens. So, particularly for a novice user who may just have one router, it would be good to have a safety net in case things go wrong. Also sometimes a user flashes OpenWrt then realise it's not for them, so for a novice-friendly devices, reverting to stock should be conveniently possible.
@tmomas wrote me a thoughtful note regarding my proposal. His questions made me think more about the motivation behind the Recommended/Limited/Difficult proposal. Rather than writing it (only) to him and then repeating it, here are my thoughts:
TL;DR: Yes, this change is primarily a "Recommendation for Newcomers to Get a Good Router". Although OpenWrt is good for many things, we are known for making a great router - it's our "brand". That's what initially makes people pay attention to the project.
I believe newcomers are our most important (untapped) resource for OpenWrt. To get them working easily on robust, reliable router only enhances the project. That's why I'm focusing the energy onto this subject.
Longer answer:
-
I want to be sure that smart people who are curious about the project can quickly see that OpenWrt could work for them. Having a clear indication of a good path forward helps. A modest set of recommended devices with straightforward installation instructions are critical for this. (Imagine the alternative: it's daunting to try to decide between 100 different devices, with conflicting "recommendations" and a tricky installation process. A router that features debricking instructions simply induces quesiness. A newcomer would feel justified staying with their crummy vendor firmware.)
-
The bump to a minimum of 16MB Flash puts us in a very good position for the future. We've been running into the 4MB limit for (over) two years as the firmware grew incrementally. Having "four times" the space (more realistically, it may only be twice as much Flash) for the base system still retains a lot of headroom for growth of packages. I can't guess how long that would be, but given the relatively slow rate of kernel growth, I suspect that people will be able to install newer OpenWrt firmware in their 16MB devices for quite a while.
-
What's the use case for these labels? I am explicitly focusing on routers. It seems that 16/128 gives us enough space to install virtually all the router-like packages in the router. (I am hopeful that it will be long time before we again have to get into the business of counting kilobytes to install a VPN package, the SQM package, the adblock package, etc.)
-
To avoid bulking up the Flash requirement, I explicitly excluded "server-kinds-of-things" from being a requirement. Setting up a file server, weather station back end, Wordpress, or even your full IT infrastructure is definitely cool, but you a) are probably already an expert, and b) can locate a device with greater capacity. (If it's confusing to have this in the bullets, we should remove it.)
-
As for Experts, these labels won't really tell them anything that they don't already recognize about their hardware. They'll likely be looking for a specific set of capabilities, and can ask cogent questions on the forum to get help.
-
A lot of members on the forum are weary of having to say, "Sorry, your router won't work with ..." I want to be protective of everyone's time, so that we don't burn out otherwise helpful and friendly people on the forum.
-
Finally, I also want to emphasize the magnificent job @tmomas has done to create and maintain the ToH infrastructure. It makes it easy for me to glibly say, "Let's just filter out all the devices that don't meet our criteria..." and get credible results. I have some thoughts on implementing this in the ToH. I'll add those to the Machine Readable topic.
Thanks again for the discussion.
3 Likes
In this same line of thinking if we can come up with a decent machine readable TOH then I think an interactive recommender using Javascript in the browser with real time filtering is probably reasonable to make. That's my goal there.
4 Likes
...but installing tftp32 is OK?
Just asking to get a clearer picture.
TFTP is available on macOS by default, by package install on major Linux-based distros, and by (it seems) tftp32 on Windows. I'm OK with that as it is readily available, "generic" software that is easily installed and removed (if needed), runs on "all" platforms, and there isn't hairy configuration involved. One wiki page for "How to set up TFTP" (it's there, but I've only poked at the macOS parts of it) should take it from "scary" to "I can do this."
"Linkgear Magic Configuration Tool" (Windows 95 required), umm, no.
2 Likes
Installing widely available software that you can get from various sources under free licenses on multiple platforms seems much better than for example what you have to do to get a MiWiFi 3G installed.
I don't see installing a web browser as a barrier, installing a tftp server is somewhat of a barrier but since there are many options and it works on every platform it's a lower barrier than say "install this Windows only firmware uploader from MANUFACTURER available here after you register " or the like.
so basically what @jeff just said (which he posted while I was writing this).
3 Likes
Uuuuuhhhhhh, no!
Got the message 
Summary of the above postings:
Easy installation is...
- can be done in approx. 15 minutes (+/-) from image download to ready flashed and working device
- without installing any additional software from a vendor (generic, non-vendor specific, easily and widely available, easily installed and removed software like a TFTP client (e.g. tftp32) is ok)
- without opening the case
- without any additional hardware required (e.g. serial adapter)
- without soldering being required
-
Flashable via GUI
- bootloader GUI
- OEM firmware GUI
- TFTP via bootloader (including installation of generic, non-vendor specific, easily and widely available software like a TFTP client (e.g. tftp32))
- can be flashed in one pass, i.e. not multiple (possibly error prone) flashing passes required to make it work
- does not require flashing twice (such as having to flash OpenWrt over both instances of OEM firmware on dual-firmware devices)
I have added a pagequery to https://openwrt.org/inbox/docs/installation/start, which results in an automatically created list of pages describing the easy installation method.
Further inclusions / exclusions can easily be done via the filters.
Your comments are welcome.
A question, not an answer:
What about devices that have to be flashed back to a "friendly" version of the OEM's firmware through the OEM's GUI?
(Such as earlier or later versions for devices that shipped not allowing unsigned firmware)
Can we add, not necessarily as a factor in classification, but at least as a column in the ToH something any debricking or reverting to stock ease?
It didn't seem an issue. It shouldn't take long or effort, and it doesn't require configuration.
The more I think about a novice-friendly install badge, the more I think it should be a human decision in the end.
Take, for example, the recent thread on the TP-WA701ND. Sure enough, it is "OEM GUI" that you can use to install the image, but apparently only after you use a hex editor on the OpenWrt-supplied image, download the image builder or build chain from OpenWrt, and re-checksum the result. https://openwrt.org/toh/tp-link/tl-wa701nd
Perhaps the database install method is used to eliminate devices from the novice-friendly badge, but a human can judge in both ways, "Yes, well, this one isn't really an OEM GUI setup, but it's bulletproof and meets all the criteria in that list, so it is novice-friendly." as well as declaring processes like the TA-WA701ND not novice-friendly,
(In my opinion, our OpenWrt proprietary tools don't get a "pass" and fall into the same category at the Linkgear tooling.)
1 Like
What is about the idea to extend flash with new cheap Winbond-Chips and 64 MB RAM which both is less than 2 dollars or focus to give EXTROOT with minimal Luci on Openwrt18.06 with FTP/NFS/CIFS-Support to extend the flash to a NAS or USB-Port?
There is still a need for the old devices. These are the only devices with working drivers for major 5 points in my eyes:
- wireguard (to have a fast, modern, simple and secure connection to your home network)
- mesh-networks (wifi)
- low power consumption (That's the major point for the "old" 432 devices)
- highest possible througput like I read with "Flow offload" / HW NAT (more than 40 MBit/s - 50 MBit/s, like the original FW often achieve around 80 MBit/s which is in my opinion still ok atm under the major focus).
- USB-Function for Print-Server/NAS/external Wifi-Extensions or to build a low power stand alone internet radio for example.
@suppenkasper0815 That's what "Difficult" means
You also should take the time to examine what devices like the GL.iNet AR300M-Lite can do for US$18, delivered. They check every point on your list, have 16 MB of flash and 128 MB or RAM, and come with OpenWrt installed at that price.
You also get what you pay for, that's one ethernet port and fast ethernet. The latter isn't a huge drawback for QCA MIPS chipsets however.
I agree with almost all the points listed.
I'm still concerned about newcomers. (A rule of thumb in software companies is that every hurdle/new step you introduce into the demo process cuts your success rate in half.)
What devices would fall off the "Recommended" list if we only allowed devices that could install OpenWrt directly from the manufacturer's web GUI? (e.g., disallow tftp, etc.) Thanks.
I would ask you to be explicit about the reasons you see for the "need for these old devices." Price? Speed of processing? Functionality? Thanks.
Immediately coming to mind are the GL.iNet offerings that have NAND (and also have 16 MB of NOR flash). They run current OpenWrt, but you can't sysupgrade from NAND to NOR (with any OpenWrt, that I know of), and OpenWrt can't support NAND on the ath79 platform until Linux 4.19 (upstream rejected the approaches currently used). This would eliminate several good low-cost and moderate-cost devices, as well as what I consider to be the only viable, dual-band, travel router on the market (the AR750S "Slate"). These can be flashed with the OEM U-Boot's GUI however.
Reminds me of myself some years ago: Wanted to get away from OEM software and compared ddwrt / openwrt.
Started with ddwrt because it offered some kind of Amazon One Click installation whereas openwrt seem rather complicated :- )
Add: Or was it the "missing" GUI after installation....not quite sure. Re-installation of packages after an upgrade for sure was a first unpleasent experience on Lede
Here is an early feature request regarding Backup & restore of additionally installed packages, feel free to vote ;- )