WRT54G Successor Falls Flat On Promises 113
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."
openWRT runs, without wireless (Score:5, Insightful)
I agree with Andrew Johnson [openwrt.org]. 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.
Firmware (Score:5, Insightful)
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.
Re:OMFG compile! (Score:5, Insightful)
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.
Re:OMFG compile! (Score:5, Insightful)
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.
Re:OMFG compile! (Score:4, Insightful)
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.