Slashdot Mirror
WRT54G Successor Falls Flat On Promises
New submitter JImbob0i0 writes: "Back in January, Linksys/Belkin made a big deal about their new router, the WRT1900AC, which they claimed was a successor to the venerable WRT54G, and how they were working with OpenWRT. They released it this week, but their promises have fallen far short. You need to apply patches (which don't apply cleanly) and compile yourself in order to get it to work... so long as you don't need wireless support. There has not been much response from Linksys on the mailing list to criticism of the improperly formatted patch dump and poor reviews as a result."
they clearly missed the ball on there about what made the previous model useful.
I mean, for 400 bucks you could pick up two minnowboards.
or like, 7 raspberry pi's with wifi.
or like, 10 normal home wifi routers.
400 bucks why bother with their gpl dancing around. you can buy a frigging dualcore laptop for that money and enjoy out of the box webcam hosting, ethernet + wifi routing with a built in high resolution display and built in ups!
world was created 5 seconds before this post as it is.
I agree with Andrew Johnson. Almost everyone will want a wireless router. A Linux, open-source, router was the segment that the WRT54GL filled.
It's a bit of a shame. I need a bunch of new routers with wireless support and ideally cellular support too.
So, Linksys' OpenWRT router ships without OpenWRT firmware, apparently because there is no such firmware. You could compile such a firmware yourself, if not for Linksys withholding the wireless drivers.
I can't even begin to imagine a chain of events that resulted in shipping an OpenWRT router without any OpenWRT support.
DATABASE WOW WOW
I thought Soulskill was a shell script. :)
Aren't stories automatically selected by upvoting on firehose?
Holy crap you have to actually compile it yourself! What is the world coming to? You mean hacking isn’t just plugging stuff together?
OK the thing has problems, that’s news. But if compiling is considered hard, well, it’s hard to see you as a nerd.
RTFA. The patches are a mess, don't compile cleanly and the wireless driver is missing. Rendering it an expensive paperweight.
Because often times compiling things like this, especially what is essentially an entire fucking Linux distribution, and ESPECIALLY AGAIN one that requires cross compiling this, is rather a pain in the ass. Unless somebody has pre-built the toolchain for you, preconfigured it, etc, you're looking at at least 45 minutes of work, not counting the time for the compiler to do its actual work. That's also working under the assumption that you know how to operate the compiler (I'm assuming GCC) fairly well.
I don't know about you, but in spite of using Linux for over 10 years, unless an application I've downloaded in source form already has the build scripts configured, I'll never get the damn thing to compile. (Well, in cases where it's a single .c file with few dependencies it's not a huge deal, but even then cross compiling requires yet more work.)
Configuring make scripts and all of that crap are just not my thing. I've never been into programming anything beyond interpreted languages to be honest. Stuff like writing Bash scripts is easy for me, but I don't like to mess with C mainly because when compilers throw errors I often don't know jack shit about how to solve them, and asking for help on them usually results in me getting trolled or somebody pointing me to one of those god awful man pages.
Careful with names containing L slashdot.org/~AiphaWolf_HK slashdot.org/~AlphaWoif_HK slashdot.org/~AiphaWoif_HK
So basically they are saying since the firmware they are providing will compile (even though it doesn't contain any wireless support) is still a firmware so they are technically holding up on their end of the bargain. This is just really obtuse.
So nerd or not there is no amount of compiling that will actually make this WIFI router actually connect any WIFI devices.
A loop, by its nature, continues. If that didn't make sense, start reading this sentence again.
If the problems can be fixed by the early adopters on the bleeding edge compiling code that has been supplied to them then a more user-friendly patch is probably only a few days away.
Early adopters to something ambitious should expect a hiccup every now and again.
You know the man pages are the manual right?
How about you bother to learn something instead of coasting on the work of others for a decade then complaining things don't fulfil your every need after you've contributed exactly bugger all.
As someone who has worked on a Linux-based embedded system, and had to cross-compile to do it... dude, Linux cross-compilation sucks, and there's almost universal pushback from everyone wo deals with Linux build systems, from Debian to Red Hat, and beyond, to any attempts to make it better.
IMO, you should be able to download and install OpenFriggingSolaris on a SPARC system, and cross-compile Linux for ARM, Alpha, and Intel on the damn thing, without having to have some dumb-ass chroot environment because someone is too stupid to deal with include paths, library paths, and source paths correctly, and because the build process somehow thinks it's an OK thing to use build products created during the build process as part of subsequent build steps. I mean, how incredibly, obviously stupid is it to use intermediate build products as part of your build process, unless they are targeted solely at your host environment, and never mirrored into your target build product area (oh yea, a working "DESTDIR=" would be kinda helpful here, too...).
The whole idea that you can have dependencies that reference files in the host environment other than those on a mounted read-only source partition, and that "retry" package builds each time because the build system is too stupid to figure out missing dependencies is terrifically annoying.
I work for a company which installs and deploys home / business networks for home automation purposes, and EVERY Linksys device we have tested, has inevitably ended up in the bin, not because they were faulty, but because they turned out to be rubbish.
Linksys has a long history of producing unstable devices, and their original WRT54GL Linux router's only redeeming feature was that it was open source. The interface was terrible, and so was the firmware. In fact, we aren't only talking routers, because we noticed that some of Linksys's cheap gigabit switches had issues with stuttering when playing media (no other switches were affected by this issue, including 10/100 cisco ones). It's particularly pathetic given that Blu-ray requires only 54mbps to stream.
Even assuming that patches are supplied which fixes the issues with this router, unless Linksys seriously has seriously improved their development team, and their hardware, you would be far better off with a cheap TP-Link which acts solely as a router/ADSL modem, a switch which manages the network traffic (NOT A LINKSYS ONE), and Unifi's for your Wifi (those are a dream to roll out in bulk, and the new Unifi software if it comes will even support Seamless wireless WITHOUT an expensive hardware controller).
Further evidence, we didn't even want to risk selling our used Linksys equipment on eBay and damage our seller rating (it was worth the write-off)..
As someone who has worked on a Linux-based embedded system, and had to cross-compile to do it... dude, Linux cross-compilation sucks, and there's almost universal pushback from everyone wo deals with Linux build systems, from Debian to Red Hat, and beyond, to any attempts to make it better.
Did you try OpenEmbedded / the Yocto Project? It takes away pretty much all of the pain of cross-compilation. Most of our users seem pretty happy with it.
Yocto has a different goal than cross-building a standard Linux distribution, along with some components. I was specifically involved in ChromeOS, and the cross-build wasn't there fore something as large as a complete Debian distribution.
I think the big problem with Yocto and OpenEmbedded (or ChromeOS) is that it assumes a Linux host environment, and acess through the host environment to package management tools.
I admit that there was a lot of intrinsic bias because of the team's history towards a Debian-based system, but our desktops were a Debian-style environment as well (Ubuntu), and the common implementation was to chroot into a more or less "pure" Debian build environment on the desktop, and then from that, chroot into a cross-build environment basically identical to the first chroot environment, and from that do the cross-build, including installing build products from the second chroot into the build environment for the target, and using them.
Neither Yocto nor OpenEmbedded addresses this issue adequately -- while Yocto did something to eliminate about half the hassle when Richard Purdie did his patch set last October, I don't think it was enough to get to the point where you could base a ChromeOS on it; you could use it for a single embedded device, and, with a lot of work, a number of packages on the device, but clearly nothing like all the software (which I freely admit - it's too much code) needed to do the full product, or do it in a way that was convincing enough that the additional work warranted abandoning a working (non-cross) environment.
OpenWRT developer Felix Fietkau has something different to say:
"Quick update on this subject: Linksys has now posted a GPL source for the WRT1900AC, and it contains the wifi driver sources. It appears to me, that this driver was properly licensed under GPL, with proper license headers in all source files."
Of course, this is Linksys code so...
As I anticipated, the code quality of the driver source code is abysmal. This looks like rewrite (not cleanup) material, ugly enough to cause eye cancer or frighten small children ;)
The issue here isn't that there is no wireless support, just that it's of codethulhu quality.