Thanks, @hnyman for refreshing our memories about the CC release notes.
You're right about the detailed change/update info. Those were well described. But the release notes above, from May, June, and July 2016 don't give any indication of a time frame for when the software would be "done", nor about the expected stability of each release.
Without those cues, it was hard for me to judge where the builds crossed my willingness for experimentation/threshold for pain to know when to jump in.
I am hopeful that the LEDE release notes will set the expectation that the firmware is stable, we would release as-is (modulo bugs) and real soon, and contain a corresponding exhortation to start testing now.
Switching from the absolute hell that is OPNsense, they did a couple things correctly...
1.) You can actually upgrade packages (kernel) without re-installing the OS.
1b.) This means you can update your system without having to re-install every package by hand afterwards.
2.) Unbound doesn't magically kill DNSMasq; there's a service status on each equivalent LuCI page.
3.) Equivalent mwan3 actually works and isn't completely broken...
3a.) https://github.com/Adze1502/mwan/issues/19
3b.) https://github.com/openwrt/packages/issues/3486
3c.) httpx://github.com/openwrt/packages/issues/3110
There's definitely some warts for anyone coming from Chaos Calmer, and room for improvement. Tackling 2 and 3 would, in my honest opinion, be blockers for a release. Point 1 being a pretty terrible usability issue. The ath10k and ath9k airtime fairness patches should definitely be present, and it's a shame we're using a non-LTS kernel...
Being able to upgrade the whole system, including the kernel, in-place comes at a price, by requiring quite a bit more main storage (and a semi-standard way of booting). Unfortunately neither of this is possible on the main target device range currently used for LEDE, namely the 4-16 MB flash devices with only little more RAM. To actually accomplish this, you'd need somewhere around 300-500 MB main storage and either some kind of UEFI/ BIOS or a multi-stage bootloader which can load kernel/ initramfs from a filesystem, rather than from device specific locations - and much more effort when it comes to packaging (proper library versioning, much more involved maintainer scripts).
The current top end devices (IPQ806* in particular, especially those using NAND flash and UBI, if you disregard the the more devboard like specimens (sunxi, RPi, etc.)) aren't that far away from making this a reality, but it will probably take five more year before you can expect this kind of system requirements as a baseline - and for those (future) devices, it might actually be easier not to take LEDE as a base, but slim down a more generic linux distribution instead.
Besides this being completely irrelevant; no, you're not correct. If you buffer 8M for a kernel, initramfs (if desired), and other essential boot services; your jffs2 can always be at a stable address going forward and allows for this quite easily. Asus (Tomato) figured this out years ago, OpenWRT is just really behind on everything but providing the latest software (obviously at a cost, as witnessed above).
There's long been a focus in OpenWRT of providing the latest software with almost no UX testing, not considering the smaller devices like a WRT54G which was dropped before CC (and long unusable prior). I was hoping this was going to improve with LEDE, but based on the fact userspace is in such poor shape on amd64 it looks like it's only gotten worse.
This would be very easy to implement if LEDE would only support x86 and a number of high end ARM systems, unfortunately its origin and niche are low end systems that can barely host a kernel and basic rootfs. It runs on higher end systems too, but the lower end of the hardware spectrum dictates the possible features, not the upper bound.
This is why seemingly simple or common things like in-place updates simply aren't there. This is not meant to be an excuse, but just to give some context.
Both of these packages are maintained outside of LEDE and OpenWrt, which also highlights an important difference between LEDE or OpenWrt and firmware projects like pfSense, DD-Wrt or Tomato; the latter alternatives aim for being an integrated OS with a defined base line feature set which may or may not be extensible through plugins and user provided packages.
On the other hand, LEDE or OpenWrt at least give you the ability to build unanticipated things with it, to port it to a totally different platform or to simply use it as a toolchain to compile software, something which tends to be hard with the more integrated alternative project.
LEDE, in its current form and scope, is a platform to build things on which is closer to something like Linux From Scratch than to a proper distro like Debian or a tightly integrated OS like pfSense / Tomato.
Does that mean that it has poorer UX compared to e.g. Tomato? Certainly. Does it mean that it is less stable compared to something like Tomato? Maybe, after all those projects essentially repackaging proprietary drivers do not need to update kernels and wireless drivers that often and possibilities are defined by what the original GPL code drop allows for.
I'd say that the majority of popular devices supported by LEDE do not even have 8MB flash to begin with, so we cannot really use this technique (yet). Tomato is in a better situation here as it simply has to support a range of quite similar, well equipped hardware without being constrained by less capable platforms.
The WRT54G support was dropped because it is impossible to run modern Linux on it. Both b43 and and the proprietary driver made the device run out of memory quite easily and there was no manpower to maintain two kernel tress (2.4 and 2.6) in the long run.
Could you elaborate on that? Do you have any specific pointers or suggestions for improvement?
I totally get it, but not providing it at all for any modern devices (talking an RT-N16 here, from 2010) is user hostile. There's weekly security and defect fixes shipped by the OPNsense camp, this is just not possible with the present LEDE model. Maybe I'm asking too much.
[quote="jow, post:26, topic:552"]
Both of these packages are maintained outside of LEDE and OpenWrt, which also highlights an important difference between LEDE or OpenWrt and firmware projects like pfSense, DD-Wrt or Tomato; the latter alternatives aim for being an integrated OS with a defined base line feature set which may or may not be extensible through plugins and user provided packages.
[/quote] That's kind of the thing though, if LEDE and OpenWRT are shipping pre-built flashable binaries, LEDE changes from a platform to do cool things; like install alsa and mpd and use that wireless speaker on your AP (similar to the Ubiquity education stuff), to a Tomato, pfSense, or DD-WRT. mwan3 is in the OpenWRT tree, and there's a LuCI script for it; it's not an obscure package. Pinning something as stable, and then shipping broken code marked as stable will just make users think LEDE is broken because Chaos Calmer still works.
[quote="jow, post:26, topic:552"]
what the original GPL code drop allows for.
[/quote] I back ported (FQ-)Codel to 2.6.36 from what became 3.9(?), something like that. That doesn't limit these platforms, just what you can and can't change to still load that ol' closed blob .ko.
8MB was a wild number (and really large number for a base image), much less then the number proposed by slh for this. The number is on a target by target basis, but again that's the problem. Previously you were able to install LuCI (1) and still have some flash remaining to do things on a 4M box, I had to walk my friend through how to install packages in RAM on his old linksys in LEDE...
[quote="jow, post:26, topic:552"]
Do you have any specific pointers or suggestions for improvement?
[/quote] Maintain a git repo for each package underneath the LEDE github. In the master repo (a new one could even be used) use submodules and point to a revision that should be shipped with every build. After these packages are tested, and vetted are they marked as stable. This is how Gentoo does it, and it's very similar to how AlliedModders does it for the 20?+ games that are supported.
I can hop on IRC or something else if that helps explain what this looks like to someone outside of the LEDE camp better.
Thanks for these thoughts @KyleSanderson They give us something to consider as LEDE matures.
However, they're a little OT for this particular thread (which is what "What do we need to do to ship our first stable release...")
There's a real tension between helping current folks who have older equipment vs. stunting the growth of the platform because we can't rely on enough RAM to add anything new. It seems that you're raising a couple different subjects that bear full discussion:
Looking toward legacy equipment: What is our desire/obligation/mission to provide full support for older devices? What's the cutoff point: 8MB or 16 MB flash and similar constraints on RAM? Some manufacture date? Popularity?
Looking toward the future: What kinds of auto-update/security fix/new-shiny-thing model do we want to pursue? What attributes of other projects are attractive that we would want to embrace?
I would encourage you to formulate those questions on separate topics in the forum. (Actually, I might ask you to hang onto these questions for a few weeks while the LEDE community goes hammer-and-tongs to finalize our plans for the first stable release. Once that's well-started, there'll be an opportunity to divert brain cycles to these new topics.) Thanks.
That means, 16MB RAM is definetely too little to run LEDE?
It depends on the chipset. In the case of the WRT54G series, the driver made it
so that 16MB ram was too tight for general use (someone could build a stripped
down version that would work well, but not one including 'standard' features)
other drivers aren't as memory hungry, so can still operate with 16MB
[quote="richb-hanover, post:29, topic:552"]
However, they're a little OT for this particular thread (which is what "What do we need to do to ship our first stable release...")
[/quote] That's kind of what I'm drawing on, userspace packages have regressed since Chaos Calmer and should probably be tested before marking something as stable; step 1. I know when I did an allmod network config, LEDE bailed pretty hard with actual errors in various, popular and used, components such as samba and squid.
The rest, are suggestions for legacy defect fixes and how to manage them.
Would it not make sense to have a xxxx-version-blocker tag (https://bugs.lede-project.org/) to enable users to tag issue blocking issues for a release. I also would like see all issues dev. work on in there. Not only user reported issues. I have been told that dev. have their own private lists of issues they work on. That make is really hard to us outsiders to know what is getting worked on, why and what suggested solutions are made to solve it.
That's kind of what I'm drawing on, userspace packages have regressed since
Chaos Calmer and should probably be tested before marking something as stable;
step 1. I know when I did an allmod network config, LEDE bailed pretty hard
with actual errors in various, popular and used, components such as samba and
squid.
regressions have to be noticed and reported before they can be fixed. LEDE
supports LOTS of packages, it's not possible to regression test them all.
allmod config isn't always a good test because there can be conflicts between
packages that it compiles.
Would it not make sense to have a xxxx-version-blocker tag
(https://bugs.lede-project.org/) to enable users to tag issue blocking issues
for a release. I also would like see all issues dev. work on in there. Not
only user reported issues. I have been told that dev. have their own private
lists of issues they work on. That make is really hard to us outsiders to know
what is getting worked on, why and what suggested solutions are made to solve
it.
allowing anyone to mark a bug report as a release blocker is probably going to
create as much noise as data.
Well, the user first must have a account, then find the tag and then use it. My experience is that almost no one use these except the developer that is working on that part of the code. A end user have no knowledge that this issue block any upcoming stable release. A end user is often not sure it is a real issue or simply a user error. A end user will tag it as critical, that happen. Often since the user feel it is critical for him/here/it but that is quite normal. Sometimes annoying, but that is all. Tags are to be removed and changed.
I mean, blocker must be tagged in some way, allowing the bug tracker to filter them out and create lists of them. I do not understand how the bug tracker can do it without some kind of visible tag? You could wrap some tags in a higher user level/group policy then again these is also add admin overhead that is never fun. Perhaps address the problem if it ever surface?
