Wait two years. That should be about when they get dumped because of lack of sales, and corporate ADD on the part of Microsoft.

Admittedly, one of the reasons Cisco bought them was because so many people didn't need maximum-speed minimum-latency ASIC-based routing (and certainly not L3 switching) in an era when 32 bit CPUs were cheap enough for consumer gear; being able to remotely get a CLI on a device in another city and individually control ports; or even the plethora of different standards to link multiple offices. (A simple watchdog timer would have been nice in Linksys gear, though.) A good part of the price of Cisco gear can be justified simply by not having to travel multiple hours just to push a button to reboot something. A lot of very small companies didn't need that, which is why Cisco was scared enough of market erosion to buy them.. But your example shows just how bad it was to forcibly re-brand everything as Cisco.

I'm sure the reason Cisco did the rebranding was simply out of their habit of Acquire and Absorb. This worked for enterprise stuff that was a somewhat niche market when Cisco bought them, when the acquisition was a good fit for their switching/routing architecture. But Linksys wasn't enterprise stuff. And Cisco didn't understand consumer stuff. Or the consumer market.

And then there was the "red-headed stepchild" angle. I was a Cisco employee at the time of the acquisition. We couldn't even buy Linksys gear at a decent discount through the employee hardware purchase program. I wanted a Linksys 24-port gigabit switch to use at home. Guess who I bought it from? Dell.com had the best price, and it was easier to order, too.

It also doesn't help that half of the codes out there in the wild are just raw timing codes that don't even identify the protocol, much less the bit patterns. And then the LIRC code library (which is a little better about pulling out some of the bit patterns, though not necessarily identifying the specific protocol) is primarily based around actual remotes and their manufacturer part numbers, not the receiving devices or their code sets.

It also isn't and can't be as easy as getting hash codes for a CD when you insert it. To get good timing information when reading an IR signal, you really need something based on a microcontroller, whether a USB or a standalone device.

And then it buffers the button presses so that it will still be sending codes for a moment after you push a button multiple times.

Oh, and I forgot to mention how it "buffers" keypresses. If you press the volume up button ten times, you GET ten volume ups, but they'll keep coming out after you stop pressing, because it didn't send them as fast as you pressed them. After all, we can't have just the configurator app be laggy, now can we?

Network latency? It's a laggy piece of shit Java crapplet. Unless they're literally sending mouse clicks and drags through to their servers to run the UI, what you are seeing is simply its natural crappiness.

Oh wait, it's not flash, it's a JAVA crapplet. It won't even run on Seamonkey, which I use for regular web browsing, probably because I've castrated Java in there. I have to fire up Safari to get it to run.

Have you actually used that piece of shit? It is a laggy flash (?) app. And by laggy, I mean you click on something and it takes long enough to respond that you think your click didn't work, and you end up clicking again. It's even worse when you have to click AND drag something. And then the UI is overly complex on top of that.

I have one and I really don't like it, even when you don't count the "cloud" programming crap. First of all, their "our remote knows better than you what mode it's in" crap. I prefer the super macro button approach I was using with one of the better One For All remotes, but it didn't have the code set I needed for some things. And even though I can reprogram the I2C EEPROM inside, the actual programming of OFA remotes looks like a pain in the ass, and the community grew around people who thought Excel was a really good tool for creating the programming.

Then if the remote falls on the floor, it loses power long enough to reset and decide that nothing is turned on, so you have to cover the IR LEDs with your hand and press the appropriate group button. If you don't cover it, the devices which only have a toggle on/off command will be turned off.

But the worst is how it controls my Sharp LCD TV. It sends the ON command, then the INPUT button, then the number 3. Which would be great except that it sends the INPUT code about a second before the TV is ready, so if I haven't turned the remote away so that the TV can't see it, it tunes the TV to RF channel 3. Then you have to use the Help button for a game of Twenty Questions while it tries to guess what went wrong, always in the same sequence where it takes five of them to set the input back..

My next remote is going to be a microcontroller running my own fucking code, probably crammed into a salvaged remote control shell with buttons that have a good feel. It's been a long time since Woz and his Cloud 9 remote. Remote control codes aren't exactly rocket science, and microcontrollers are really powerful these days, if you don't mind a little QFP soldering.

http://slashdot.org/~Jeremiah+Cornelius

Nobody. Fucking. Cares.

Take your paranoid CONINTELPRO crap to infowars/prisonplanet where they will love it.

The main problem is that most of the software to run programmers (beyond simple EEPROMs, etc.) is proprietary, running under Windows, or DOS for the really old stuff. The reason for it to be proprietary is because the chip makers want NDAs on the programming algorithms.

The only true success I had was an old BP-1 serial port programmer, which is limited to 64K chips, but supports programming via XMODEM (and I think YMODEM) downloads. I have a Needham's EMP-31 with a USB port, but Parallels just wasn't up to emulating the USB sufficiently for it to work a few years ago when I tried it. But now I have a cheap Dull unInspiron with a real parallel port that I can dedicate to this function.

A used BP or Needham's programmer (make sure the Needham's has the personality modules!) is a good bet. For the price of a crappy Willem, you can have a professional programmer. Just be patient and watch for a good deal.

Also (because most of these are parallel port programmers), make sure that your PC has a genuine ISA-bus LPT port. Most of these will simply not work with PCI printer ports.

Good ol' Slashdot non-editors. Indeed, there's basically no way this chip can run Linux, at least not the way most of us know Linux. It's an ARM Cortex M3 (Thumb-2 instruction set only) with 512K flash and 64K RAM (about the maximum on CM3 these days), and has no external memory bus.

The mbed board is kind of nice, in that it also has a Cortex A-something chip that loads the 1768's flash from the last file saved to its small USB stick filesystem, and does a few other things. The idea is that once your project is finished, you can use it on a naked 1768 on your own board. There's also a "cloud"-based compiler for it (IDE and compiler are both a web service). It's interesting but all I'm going to say is check mbed.org, and that the board comes with a one-time-use (I think) registration code for the cloud compiler.

Damn, you actually think $100 is okay to get current? With FFXI you can get it with all current expansions for $15, sometimes less. (the code you get also works to fullly upgrade existing accounts) And I think that also includes the first month free for new accounts.

LOL WTF BBQ