Joined: 03 Aug 2014 Posts: 41 Location: Kyiv, Ukraine
Posted: Mon Jun 13, 2016 8:26 Post subject: New mipsel dd-wrt linux3 Optware feed?
Hi all,
I am Optware-ng project maintainer. Optware-ng is the official modern Optware fork. It currently works on hardware of any supported arch, as long as the kernel isn't older than the headers used in the toolchains. It's been tested to work fine on DD-WRT routers, after emptying LD_LIBRARY_PATH env variable (see https://github.com/Optware/Optware-ng/issues/120). While the ARMv7 sofltfloat feed uses 2.6.36.4 kernel headers, which are modern enough for most of the packages, the same is not true for the MIPSEL feed. Many, if not most, of MIPSEL router firmwares are running 2.6.22.19 kernels, hence the feed uses 2.6.22.19 kernel headers as well. The recently added OpenZWave packages (see https://github.com/Optware/Optware-ng/issues/119) require newer kernel, and I suspect that in time there'll be more packages of this kind that won't build with the 2.6.22.19 toolchain. This left me thinking that it makes sense to add a linux3 MIPSEL feed, specifically for firmwares running on top of 3.X kernels, like DD-WRT K3.X builds. This brings up the question to you, DD-WRT users and gurus: which kernel headers version I should use? It should be the lowest among the widely used 3.X kernel versions. And, of course, does it really make sense to add such a feed: will it attract interest in the DD-WRT community? Maybe now, that Optware-ng is official, and is built and hosted by the nslu2-linux, it makes sense to update the DD-WRT wiki, so that wider audience is aware of the opportunities it brings?
Joined: 03 Aug 2014 Posts: 41 Location: Kyiv, Ukraine
Posted: Thu Jun 16, 2016 18:35 Post subject:
OK, I'm a bit surprised there's no interest in this, maybe this is due to an ill-named thread, so I try to make it a bit more informative, and sorry for the bump. If it's really unneeded by DD-WRT community, than Optware-ng will do without linux3 mipsel feed, since DD-WRT is probably the only widespread embedded linux3 mipsel32 platform (apart from OpenWRT, but they have repos of their own).
i don't think the "no interest" is due to the thread name but more to the fact that the internet has become a very very dangerous place and people have developed major trust issues and prefer to stay with what they know. I for one suffer from this
I saw this Optware some time aback and just decided to leave it alone due to the fact that it is reletivly new and the "trust" in the fw just isn't there IMO. It could be because i have never used it or thati don't frequent the forums.
Thanks for creating this feed. I personally use the feeds on both my R7000 and RT-AC66(MIPSEL). The package I currently use is basically just python. And it works well on both for what I need it to do. So can't comment on if we need a separate feed for 3.x. I think if eventually things stop working I might be interested in a 3.x feed but until then I am ok. May be others can pitch in with their opinions as well.
Joined: 03 Aug 2014 Posts: 41 Location: Kyiv, Ukraine
Posted: Fri Jun 17, 2016 7:59 Post subject:
Brimmy wrote:
Hi,
i don't think the "no interest" is due to the thread name but more to the fact that the internet has become a very very dangerous place and people have developed major trust issues and prefer to stay with what they know. I for one suffer from this
I saw this Optware some time aback and just decided to leave it alone due to the fact that it is reletivly new and the "trust" in the fw just isn't there IMO. It could be because i have never used it or thati don't frequent the forums.
Hi Brimmy,
I understand your concerns about security. While I can't give you absolute guarantees, there're some things that can however alleviate some of the possible fears:
* Optware is not a firmware, and is much more less likely to cause damage to hardware, unless you try very hard to do so
* Optware doesn't almost interfere with what your firmware does, the number of packages that can do this is very limited, and have to be installed explicitly.
* In case a package renders your fw unstable, like eating away too much resources, it can be easily uninstalled.
* None of the Optware packages, to the extent of my knowledge, are aware of nvram or jffs, and since the rootfs is read-only, they're unlikely to cause damage to your data.
* In case a package has to be upgraded/patched for security reasons, you can always create an issue on github, and I'll do my best to fix it as soon as I can
Also, Optware-ng is now the official nslu2-linux continuation of the good old trusted Optware (which is unusable on recent dd-wrt fws), if that makes a difference to you
nathulal wrote:
Hi Alexx,
Thanks for creating this feed. I personally use the feeds on both my R7000 and RT-AC66(MIPSEL). The package I currently use is basically just python. And it works well on both for what I need it to do. So can't comment on if we need a separate feed for 3.x. I think if eventually things stop working I might be interested in a 3.x feed but until then I am ok. May be others can pitch in with their opinions as well.
Thanks
Hi nathulal,
Thank you for the feedback! I'm very glad that it works for you. The MIPSEL feed should work fine with a 3.x kernel, the only reason for a 3.x feed would be to have packages that require newer kernels (like OpenZWave I mentioned earlier), and maybe some of the features not available for the decently old 2.6.22.19 kernel.
I think many of the folks who use optware in the past are now using entware to fulfill many of their optware needs. I, for one, converted many of the OTRW2 scripts that I use to use the entware build instead.
Couple that with the fact the Kong builds, favored by quite a few users, also includes an opkg listing as well.
Perhaps its my ignorance, or laziness, but I'm not sure I understand the qualitative difference between Optware-ng and entware. Perhaps you can provide some insight there.
Joined: 03 Aug 2014 Posts: 41 Location: Kyiv, Ukraine
Posted: Sat Jun 18, 2016 7:52 Post subject:
VTecheira wrote:
I think many of the folks who use optware in the past are now using entware to fulfill many of their optware needs. I, for one, converted many of the OTRW2 scripts that I use to use the entware build instead.
Couple that with the fact the Kong builds, favored by quite a few users, also includes an opkg listing as well.
Perhaps its my ignorance, or laziness, but I'm not sure I understand the qualitative difference between Optware-ng and entware. Perhaps you can provide some insight there.
The main difference between Optware-ng and Entware-ng is in the list of available packages. For instance, Optware-ng provides OpenJDK7 and OpenJDK8, which are not available on Entware-ng, and odds are it'll remain this way (especially OpenJDK7, which requires some X11 build dependencies due to the need to use icedtea for cross-compilation), e.g., currently the only (simple) way to run BubbleUPnPServer (http://www.bubblesoftapps.com/bubbleupnpserver) on a router, without Debian chroot, is by using Optware-ng. Optware-ng also has some working X11 and GTK+2/3 packages, though this isn't currently actively developed. For some funny reason, deluge doesn't work on Entware-ng MIPSEL, yet in Optware-ng there're two working deluge packages: deluge and deluge-develop. There's gcc available for native compilation (it can't be used with fw's libs due to different libc's, but it works fine with Optware-ng libs). Also, if there's a package you need which is missing in Optware-ng, but available on Entware-ng, it's quite likely that I can add it easily (except the golang packages, but maybe I'll add gccgo in the future), so just create an issue on github, and I'll look into it.
There's another difference when speaking about (softfloat) ARMv7: Entware-ng uses GNU lib C for this feed, while Optware-ng uses uClibc-ng, which has a considerably lower memory footprint, and works better in terms of performance. I believe this makes a difference on ARMv7 routers: they're more powerful when compared to MIPSEL ones, but in embedded every little bit counts.
BTW, ipkg used by Optware-ng is actually opkg, but newer than the one used by Entware-ng (and OpenWRT): 0.2.4. It's just patched to use ipkg paths for backward compatibility with ipkg. Most of OpenWRT opkg patches have been ported by me to this newer version.
Finally, Optware-ng binary updates under normal conditions usually roll out soon after code update is pushed to the github, so it often takes less than a day to fix reported problems.
Which is better: Entware-ng or Optware-ng? Probably, the only way to find your personal answer is to try both.
