Since getting my Samsung Tab 10.1, I haven't used my netbook much.
Since getting a Bluetooth keyboard for the Tab - the netbook hasn't been touched in months.
While the netbook is technically faster, the Tab's OS is more lightweight so in the end gives a much more pleasant user experience, and there is much to be said for having a system that can resume from suspend in well under a second, and can sit in suspend for days, waking up for push email and such. A netbook in suspend takes tens of seconds to resume, at best. So it can't maintain an active network connection and "wake up" to fire a notification when an email comes in, at least not efficiently.
THAT is the real advantage of premium tablets - the form factor of a netbook, but the power management of a mobile phone.
Not quite - if you install the standard Nook app, you lose "More in Store" and "Read in Store" - I assume the stock Color had these. (My eInk Nook does.)
Um, comparing a third-party firmware for the original Nook with the stock features of this new one isn't valid.
The better question is - Assuming that they don't lock the bootloader this time around, what will this new device be like with CM9?
If I didn't already have a Tab 10.1, I'd go for this... If the flexibility of this device is even close to that of its predecessor, it's going to be a beast with CM9. (It may get CM7 in the interim, but that's probably only going to be short-term.)
Anyone running Cyanogenmod - already has it available if they're on a Galaxy S II (note, that particular bug is GSII specific)
Anyone running a custom GSII ROM - depends on how often their ROM dev pulls in kernel updates. Most of them are pretty good about pulling in updates when a significant kernel bugfix is found.
How long before normal users who didn't pay $99/year to be a developer get the fix?
As I said - in one case, we had a turnaround of less than a day from seeing something odd in/proc/wakelocks to kernel fixes being deployed. Really, how much testing do you need for changing an == to the >= it clearly should have been in a fuel gauge driver?
"They are unlikely to be faster, unless they don't test."
Utter bullshit... AT&T, for example, is notorious for holding up releases in the name of "Testing" only to release a bloated piece of crap that has bugs added compared to the international firmware that was ported to an AT&T device with only 1-2 weeks of effort.
Saw fuel_alerted in/proc/wakelocks causing someone's device to stay awake for multiple hours Grepped for fuel_alerted to find the relevant source code file Read the file Had a fix implemented within 30 minutes in my own kernel of reading the wakelocks dump The fix was deployed to Cyanogenmod kernels within 1-2 days for the I777 Numerous other kernel developers picked it up within 1-2 weeks
Apple users, on the other hand, had at least 2-3 weeks of complaints before the company even acknowledged there was a fucking bug. They'll be waiting at least another week or two more, if they're lucky.
WRT54GL is identical to an old-rev WRT54G prior to Linksys dropping the RAM/ROM and switching to vxWorks.
Because of the lack of documentation, these routers were stuck with an ancient Linux kernel revision for a long time - no improvements to the network stack, etc.
2.6 porting seems to have started in 2006-2007 - but as of late 2009, kernel 2.6-based firmwares on any Broadcom-based router were still highly unstable/buggy in terms of wireless capability.
My point is not that the gear is shit - but that if you're purchasing a device to hack it (Again - look at the post I originally was replied to, from someone who was looking for a "super-arduino"), you need to avoid Broadcom like the plague. Also, if you want to be able to track whatever software enhancements might be possible for your device and not be stuck on firmware that is ancient, again, you need to avoid Broadcom like the plague.
Yup, and I admit - we've got battery problems that can affect people too. (Exchange calendar sync bug, Skype, Words with Friends, and I know of one kernel bug that affected a few people which I've fixed.) However we've got far better tools for drain-hunting than iOS, and we don't have to wait for upstream to fix our problems either.
You mean the WRT54GL for which Linux 2.6 support was still unstable in late 2009, despite Linux 2.6 being first released in 2003, because of the fact that Broadcom refused to provide any chipset documentation?
It appears HP still had committments with suppliers to purchase parts - so there was one final production run as it was likely more profitable to build the parts into firesale TouchPads than to just write them off.
The only reason it took off at that price point was because it entered the "impulse buy" category for many people.
It also entered the "hack toy" category for many - Nearly everyone I know who scored a firesale TouchPad only had its stock OS as their "backup plan" - their main plan was to follow Android porting efforts for the device. That's why I tried to score a TouchPad, for example.
Had HP sold the TouchPad with Android, they would have at least managed to stay afloat in the market... It is possible to "stay alive" in the Android tablet market at the $500 price point. But $500 for a niche OS with declining marketshare - well, you're toast.
Similarly - every attempt to shoehorn a desktop OS into a tablet has been a failure, and it will continue to be that way. Win8 might be an exception because MS seems to be trying to make Win8 a "scaled up" version of WP7.
A little more info, more along the lines of why there is so much generic Broadcom hate and distrust within the Linux community:
http://linuxwireless.org/en/users/Drivers/b43 - If you go down about 3/4 of the page, you'll see that: Until 9/9/2010, the only drivers for ANY broadcom device were created via reverse engineering. Broadcom provided ZERO support to the b43 developers, and I'm fairly certain they still don't have any proper technical documentation. (Sorry Broadcom, but source code isn't documentation.) After 9/9/2010 - only THREE chipsets (out of quite many) had any sort of "official" open source driver support for Linux from Broadcom.
Meanwhile, chipsets from other manufacturers (Intel, Atheros, Intersil/Harris, Ralink) have had robust open source support for a VERY long time. For many years, Broadcom WLAN chipsets were completely useless in Linux due to Broadcom's refusal to provide any documentation.
Yeah, Gumstix is kinda need for embedded work too. If you want video interfaces, the BeagleBoard is the way to go. The problem is that accessing the GPIO/SPI/I2C etc of the Beagle is pretty difficult just due to how the headers are laid out. There also isn't that much "nifty I/O" for embedded work on the Beagle, as its processor is more "general purpose" oriented.
The Bone is an entirely different animal - much more GPIO and more flexible I/O.
The SPI interfaces on that Sitara are insane... They appear to be able to run at tens of megahertz clock rate, there's two McSPIs, and each supports two enable lines.
I've had a project in mind for a while that would have a Xilinx Spartan-3E's BRAM exposed to a host processor via SPI - Originally I was going to use an LM3S6965 as the host, but the Sitara will be much easier. The BeagleBoard's expansion arrangement would've made this very difficult.
If you read the post I replied to, it's clear that the person I replied to is focused more on the embedded control in their desires than on having a general-purpose PC.
"Not sure where the hate is coming from here." Where's the TRM? Where's the datasheet? That's where the hate is coming from. That and years of bad memories involving Broadcom WLAN chipsets on Linux due to lack of datasheet access (and, in general, lack of access to any documentation at all)
For someone like the OP who is planning on doing embedded computing (by necessity, more "low-level" than just using the device as an STB), having a processor datashete is an absolute and complete necessity
Since the BCM2835's datasheet is not available (in typical Broadcom style) - why even bother wasting board space on a GPIO/SPI/I2C header that no one who purchases the Pi is going to be able to be able to use?
The GPIO expansion ports have been intentionally made difficult to access on the Pi (to eliminate risk of accidentally plugging in something that makes it unhappy is the claim, but probably the real reason is that easy physical access to the ports would more rapidly piss off those who buy it and realize the BCM2835 datasheet isn't available unless you're a megacorporation or an ex-employee like Eben is.) Heck, the product page on Broadcom's website for this device is nothing but a marketing blurb. Anyone familiar with Broadcom's history with open source is not going to be surprised by this - it's typical classic Broadcom.
If you want to do embedded computing work and not just have a set-top-box without a case - look at the new BeagleBone. It's more expensive, but with a significantly faster CPU (same clock speed, but the Cortex-A8 does much better than the ARM11 IPC-wise) and the I/O is brought out to standard 0.1" pin headers. In addition, it takes 20 seconds on Google to find the AM3358's product page, which immediately gives you an internal block diagram of the chip, and the full TRM (datasheet) for the chip is right near the top of the page.
Natural gas may burn clean, but it sure as hell doesn't extract clean.
You clearly don't live on top of the Marcellus like I do.
I'll take a nuclear plant a mile away from me over the commencement of fracking operations any day of the week.
Much of it is due to a clear difference in attitude between the nuclear and gas industries: Nuclear: "If we fuck up, bad things will happen. So we are going to constantly improve safety designs to prevent bad things from happening." Gas drilling industry: "We're clean. We're safe. No, the rampant contamination in Dimock wasn't our fault. It was biogenic methane, forget the fact that those wells ran clean for decades before we showed up. It isn't our fault. We're clean. We're safe. Those wells aren't contaminated, you didn't see someone just light their tap water on fire. We don't need to improve because we are AWESUM DUDE!"
I have no problem fitting it into my pocket, I didn't even have any issues fitting the Infuse into my pocket and that's a 4.5" screen. They're wide/tall, but they are THIN. The iPhone is also heavy as hell compared to Samsungs, and has the shittiest antenna design I've seen in years. (I'm an RF engineer, I work with RF engineers, we laughed at the iPhone 4.) In terms of pocketability, I'm far more comfortable with the Samsung's plastic back not getting damaged by my Leatherman or Fenix LD01 than the iPhone's glass back (heavy and less durable). Plastic != cheap - properly designed plastics are extremely durable (see Samsung drop tests as one example.)
As to crappy screen - 960x640 is an utter waste in a 3.5" screen. I'd prefer to not have to hold the phone inches from my face while watching a movie, and I like being able to see my phone's display when it's sitting in the car dock running Google Maps Navigation without having to lean forward to see what my next turn is.
And then you actually brought IPS into the picture - any AMOLED screen's black levels and contrast ratio blow away any LCD screens. Now, early AMOLED screens had the deficiency of PenTile subpixel arrangements, but the GSII's screen is a sAMOLED+ display, which does not have that stupid PenTile subpixel arrangement.
So yeah - the iPhone 4 has a crappy screen. Resolution like that is irrelevant in a screen size that small. It's the same reason you rarely see 32" 1080p TVs - it's an utter and total waste.
Quite a few - Samsung's hottest seller in late spring/early summer was the international variant of the Galaxy S II - a device which was undoubtebly above the iPhone 4 in all regards.
In fact, in some areas, it's still ahead of the iPhone 4S - the 4S has a nicer GPU but a weaker CPU, and still has a crappy 3.5" screen.
"(unless it can cold flash, has a hard ROM for flashing, or accessible JTAG, all of which are extremely rare on consumer level devices.)" Most if not all ARM devices have a bootloader (kinda similar to BIOS) - it provides less kernel compatibility provisions than a BIOS, but, at least on Samsungs, you can't brick unless you accidentally torch the bootloader - and it's pretty hard to do that.
I've "softbricked" with bad kernels many times (I maintain a custom kernel for the Infuse and AT&T S2...). Took 30 seconds to enter download mode, fire up Heimdall, and flash a known good kernel.
Google Talk video support (requires Gingerbread) Google Maps Navigation (for those very rare devices that didn't see 2.x in any form)
However, the N1 not getting ICS doesn't seem that bad to me - the N1 is a fairly old device at this point and likely just isn't powerful enough for ICS.
Forcing an OS upgrade into a device too slow to support it isn't a good idea - look at how owners of the non-S iPhone 3 units got screwed when they updated IOS - the phone became slow to the point of being almost unusable.
Too late - I already switched to Tomato, everything just plain works better.
Seriously? From 2004 to 2011 to update inadyn?
And, of course - what bugs get included with updating to that release compared with the ancient "recommended" release for Broadcom devices?
I went through great lengths to make inadyn print more useful log info - it's kind of stupid that DD-WRT's default error reportings for inadyn cause it to report success when a failure occurs. Verbose logging showed that the server was rejecting requests, I believe (based on what I remember) because they weren't SSL.
Well, in that case - whatever development effort is remaining is being executed very poorly.
Deficiencies in older releases aren't being corrected, while new releases introduce new bugs - sounds like if it isn't dead, it's poorly developed.
inadyn in the recommended release is multiple versions old and fails on many services now. But instead of fixing the old bugs, they're just creating new ones and not touching the known-broken stuff? Last I checked, DD-WRT was including inadyn 1.6 - that was last released in 2004!!!
dd-wrt hasn't worked with no-ip.com for over a year. What's especially annoying is that it doesn't spit out any errors into the log - it just fails silently and you wonder why you keep getting inactivity nastygrams.
DD-WRT development is basically dead. There hasn't been an update on their homepage in over a year.
There are unofficial builds in the forums, but even those are at this point old. For example, the "Recommended" version for Broadcom-based devices still includes an ANCIENT release of inadyn that doesn't work with most dynamic DNS providers at this point (nearly all implemented SSL security which breaks with older inadyn.)
Tomato/TomatoUSB are the way to go at this point. (Tomato itself isn't updated much either - TomatoUSB has improved support even for non-USB devices.)
Slashdot Mirror
Every Intel-based tablet to this date has been an utter and complete failure... Intel + Win8 = good way to put an epic failure onto the market.
Since getting my Samsung Tab 10.1, I haven't used my netbook much.
Since getting a Bluetooth keyboard for the Tab - the netbook hasn't been touched in months.
While the netbook is technically faster, the Tab's OS is more lightweight so in the end gives a much more pleasant user experience, and there is much to be said for having a system that can resume from suspend in well under a second, and can sit in suspend for days, waking up for push email and such. A netbook in suspend takes tens of seconds to resume, at best. So it can't maintain an active network connection and "wake up" to fire a notification when an email comes in, at least not efficiently.
THAT is the real advantage of premium tablets - the form factor of a netbook, but the power management of a mobile phone.
Not quite - if you install the standard Nook app, you lose "More in Store" and "Read in Store" - I assume the stock Color had these. (My eInk Nook does.)
Um, comparing a third-party firmware for the original Nook with the stock features of this new one isn't valid.
The better question is - Assuming that they don't lock the bootloader this time around, what will this new device be like with CM9?
If I didn't already have a Tab 10.1, I'd go for this... If the flexibility of this device is even close to that of its predecessor, it's going to be a beast with CM9. (It may get CM7 in the interim, but that's probably only going to be short-term.)
Anyone running Cyanogenmod - already has it available if they're on a Galaxy S II (note, that particular bug is GSII specific)
Anyone running a custom GSII ROM - depends on how often their ROM dev pulls in kernel updates. Most of them are pretty good about pulling in updates when a significant kernel bugfix is found.
How long before normal users who didn't pay $99/year to be a developer get the fix?
As I said - in one case, we had a turnaround of less than a day from seeing something odd in /proc/wakelocks to kernel fixes being deployed. Really, how much testing do you need for changing an == to the >= it clearly should have been in a fuel gauge driver?
"They are unlikely to be faster, unless they don't test."
Utter bullshit... AT&T, for example, is notorious for holding up releases in the name of "Testing" only to release a bloated piece of crap that has bugs added compared to the international firmware that was ported to an AT&T device with only 1-2 weeks of effort.
As an example of a drain bug:
https://github.com/Entropy512/linux_kernel_sgh-i777/commit/fc9eb85807302583259e27013ed184a43107bb67
Saw fuel_alerted in /proc/wakelocks causing someone's device to stay awake for multiple hours
Grepped for fuel_alerted to find the relevant source code file
Read the file
Had a fix implemented within 30 minutes in my own kernel of reading the wakelocks dump
The fix was deployed to Cyanogenmod kernels within 1-2 days for the I777
Numerous other kernel developers picked it up within 1-2 weeks
Apple users, on the other hand, had at least 2-3 weeks of complaints before the company even acknowledged there was a fucking bug. They'll be waiting at least another week or two more, if they're lucky.
WRT54GL is identical to an old-rev WRT54G prior to Linksys dropping the RAM/ROM and switching to vxWorks.
Because of the lack of documentation, these routers were stuck with an ancient Linux kernel revision for a long time - no improvements to the network stack, etc.
2.6 porting seems to have started in 2006-2007 - but as of late 2009, kernel 2.6-based firmwares on any Broadcom-based router were still highly unstable/buggy in terms of wireless capability.
My point is not that the gear is shit - but that if you're purchasing a device to hack it (Again - look at the post I originally was replied to, from someone who was looking for a "super-arduino"), you need to avoid Broadcom like the plague. Also, if you want to be able to track whatever software enhancements might be possible for your device and not be stuck on firmware that is ancient, again, you need to avoid Broadcom like the plague.
Yup, and I admit - we've got battery problems that can affect people too. (Exchange calendar sync bug, Skype, Words with Friends, and I know of one kernel bug that affected a few people which I've fixed.) However we've got far better tools for drain-hunting than iOS, and we don't have to wait for upstream to fix our problems either.
You mean the WRT54GL for which Linux 2.6 support was still unstable in late 2009, despite Linux 2.6 being first released in 2003, because of the fact that Broadcom refused to provide any chipset documentation?
It appears HP still had committments with suppliers to purchase parts - so there was one final production run as it was likely more profitable to build the parts into firesale TouchPads than to just write them off.
The only reason it took off at that price point was because it entered the "impulse buy" category for many people.
It also entered the "hack toy" category for many - Nearly everyone I know who scored a firesale TouchPad only had its stock OS as their "backup plan" - their main plan was to follow Android porting efforts for the device. That's why I tried to score a TouchPad, for example.
Had HP sold the TouchPad with Android, they would have at least managed to stay afloat in the market... It is possible to "stay alive" in the Android tablet market at the $500 price point. But $500 for a niche OS with declining marketshare - well, you're toast.
Similarly - every attempt to shoehorn a desktop OS into a tablet has been a failure, and it will continue to be that way. Win8 might be an exception because MS seems to be trying to make Win8 a "scaled up" version of WP7.
A little more info, more along the lines of why there is so much generic Broadcom hate and distrust within the Linux community:
http://linuxwireless.org/en/users/Drivers/b43 - If you go down about 3/4 of the page, you'll see that:
Until 9/9/2010, the only drivers for ANY broadcom device were created via reverse engineering. Broadcom provided ZERO support to the b43 developers, and I'm fairly certain they still don't have any proper technical documentation. (Sorry Broadcom, but source code isn't documentation.)
After 9/9/2010 - only THREE chipsets (out of quite many) had any sort of "official" open source driver support for Linux from Broadcom.
Meanwhile, chipsets from other manufacturers (Intel, Atheros, Intersil/Harris, Ralink) have had robust open source support for a VERY long time. For many years, Broadcom WLAN chipsets were completely useless in Linux due to Broadcom's refusal to provide any documentation.
Yeah, Gumstix is kinda need for embedded work too. If you want video interfaces, the BeagleBoard is the way to go. The problem is that accessing the GPIO/SPI/I2C etc of the Beagle is pretty difficult just due to how the headers are laid out. There also isn't that much "nifty I/O" for embedded work on the Beagle, as its processor is more "general purpose" oriented.
The Bone is an entirely different animal - much more GPIO and more flexible I/O.
The SPI interfaces on that Sitara are insane... They appear to be able to run at tens of megahertz clock rate, there's two McSPIs, and each supports two enable lines.
I've had a project in mind for a while that would have a Xilinx Spartan-3E's BRAM exposed to a host processor via SPI - Originally I was going to use an LM3S6965 as the host, but the Sitara will be much easier. The BeagleBoard's expansion arrangement would've made this very difficult.
If you read the post I replied to, it's clear that the person I replied to is focused more on the embedded control in their desires than on having a general-purpose PC.
"Not sure where the hate is coming from here."
Where's the TRM? Where's the datasheet? That's where the hate is coming from. That and years of bad memories involving Broadcom WLAN chipsets on Linux due to lack of datasheet access (and, in general, lack of access to any documentation at all)
Compare the following webpages:
http://www.broadcom.com/products/BCM2835 - Marketing blurb, no block diagrams, no datasheets, no nothing
http://www.ti.com/product/am3358 - Block diagram, family parametric comparison, and an EXTREMELY complete datasheet
For someone like the OP who is planning on doing embedded computing (by necessity, more "low-level" than just using the device as an STB), having a processor datashete is an absolute and complete necessity
Since the BCM2835's datasheet is not available (in typical Broadcom style) - why even bother wasting board space on a GPIO/SPI/I2C header that no one who purchases the Pi is going to be able to be able to use?
The GPIO expansion ports have been intentionally made difficult to access on the Pi (to eliminate risk of accidentally plugging in something that makes it unhappy is the claim, but probably the real reason is that easy physical access to the ports would more rapidly piss off those who buy it and realize the BCM2835 datasheet isn't available unless you're a megacorporation or an ex-employee like Eben is.) Heck, the product page on Broadcom's website for this device is nothing but a marketing blurb. Anyone familiar with Broadcom's history with open source is not going to be surprised by this - it's typical classic Broadcom.
If you want to do embedded computing work and not just have a set-top-box without a case - look at the new BeagleBone. It's more expensive, but with a significantly faster CPU (same clock speed, but the Cortex-A8 does much better than the ARM11 IPC-wise) and the I/O is brought out to standard 0.1" pin headers. In addition, it takes 20 seconds on Google to find the AM3358's product page, which immediately gives you an internal block diagram of the chip, and the full TRM (datasheet) for the chip is right near the top of the page.
Natural gas may burn clean, but it sure as hell doesn't extract clean.
You clearly don't live on top of the Marcellus like I do.
I'll take a nuclear plant a mile away from me over the commencement of fracking operations any day of the week.
Much of it is due to a clear difference in attitude between the nuclear and gas industries:
Nuclear: "If we fuck up, bad things will happen. So we are going to constantly improve safety designs to prevent bad things from happening."
Gas drilling industry: "We're clean. We're safe. No, the rampant contamination in Dimock wasn't our fault. It was biogenic methane, forget the fact that those wells ran clean for decades before we showed up. It isn't our fault. We're clean. We're safe. Those wells aren't contaminated, you didn't see someone just light their tap water on fire. We don't need to improve because we are AWESUM DUDE!"
I have no problem fitting it into my pocket, I didn't even have any issues fitting the Infuse into my pocket and that's a 4.5" screen. They're wide/tall, but they are THIN. The iPhone is also heavy as hell compared to Samsungs, and has the shittiest antenna design I've seen in years. (I'm an RF engineer, I work with RF engineers, we laughed at the iPhone 4.) In terms of pocketability, I'm far more comfortable with the Samsung's plastic back not getting damaged by my Leatherman or Fenix LD01 than the iPhone's glass back (heavy and less durable). Plastic != cheap - properly designed plastics are extremely durable (see Samsung drop tests as one example.)
As to crappy screen - 960x640 is an utter waste in a 3.5" screen. I'd prefer to not have to hold the phone inches from my face while watching a movie, and I like being able to see my phone's display when it's sitting in the car dock running Google Maps Navigation without having to lean forward to see what my next turn is.
And then you actually brought IPS into the picture - any AMOLED screen's black levels and contrast ratio blow away any LCD screens. Now, early AMOLED screens had the deficiency of PenTile subpixel arrangements, but the GSII's screen is a sAMOLED+ display, which does not have that stupid PenTile subpixel arrangement.
So yeah - the iPhone 4 has a crappy screen. Resolution like that is irrelevant in a screen size that small. It's the same reason you rarely see 32" 1080p TVs - it's an utter and total waste.
Quite a few - Samsung's hottest seller in late spring/early summer was the international variant of the Galaxy S II - a device which was undoubtebly above the iPhone 4 in all regards.
In fact, in some areas, it's still ahead of the iPhone 4S - the 4S has a nicer GPU but a weaker CPU, and still has a crappy 3.5" screen.
"(unless it can cold flash, has a hard ROM for flashing, or accessible JTAG, all of which are extremely rare on consumer level devices.)"
Most if not all ARM devices have a bootloader (kinda similar to BIOS) - it provides less kernel compatibility provisions than a BIOS, but, at least on Samsungs, you can't brick unless you accidentally torch the bootloader - and it's pretty hard to do that.
I've "softbricked" with bad kernels many times (I maintain a custom kernel for the Infuse and AT&T S2...). Took 30 seconds to enter download mode, fire up Heimdall, and flash a known good kernel.
Google Talk video support (requires Gingerbread)
Google Maps Navigation (for those very rare devices that didn't see 2.x in any form)
However, the N1 not getting ICS doesn't seem that bad to me - the N1 is a fairly old device at this point and likely just isn't powerful enough for ICS.
Forcing an OS upgrade into a device too slow to support it isn't a good idea - look at how owners of the non-S iPhone 3 units got screwed when they updated IOS - the phone became slow to the point of being almost unusable.
Too late - I already switched to Tomato, everything just plain works better.
Seriously? From 2004 to 2011 to update inadyn?
And, of course - what bugs get included with updating to that release compared with the ancient "recommended" release for Broadcom devices?
I went through great lengths to make inadyn print more useful log info - it's kind of stupid that DD-WRT's default error reportings for inadyn cause it to report success when a failure occurs. Verbose logging showed that the server was rejecting requests, I believe (based on what I remember) because they weren't SSL.
Well, in that case - whatever development effort is remaining is being executed very poorly.
Deficiencies in older releases aren't being corrected, while new releases introduce new bugs - sounds like if it isn't dead, it's poorly developed.
inadyn in the recommended release is multiple versions old and fails on many services now. But instead of fixing the old bugs, they're just creating new ones and not touching the known-broken stuff? Last I checked, DD-WRT was including inadyn 1.6 - that was last released in 2004!!!
dd-wrt hasn't worked with no-ip.com for over a year. What's especially annoying is that it doesn't spit out any errors into the log - it just fails silently and you wonder why you keep getting inactivity nastygrams.
DD-WRT development is basically dead. There hasn't been an update on their homepage in over a year.
There are unofficial builds in the forums, but even those are at this point old. For example, the "Recommended" version for Broadcom-based devices still includes an ANCIENT release of inadyn that doesn't work with most dynamic DNS providers at this point (nearly all implemented SSL security which breaks with older inadyn.)
Tomato/TomatoUSB are the way to go at this point. (Tomato itself isn't updated much either - TomatoUSB has improved support even for non-USB devices.)