It is not DRM that enforces it. In fact, I don't think you understand what DRM is.
If I write a proprietary video player, using a proprietary codec, and I stream you videos that only work in that player, that is not DRM just because I was too lazy to provide you a local caching method.
DRM is not "make it inconvenient for me to use with something else". Digital Rights Management is verifying that playback is appropriately licensed. That's it. A key requirement of any DRM schemes is "make it inconvenient to copy" and "make it inconvenient to play with something else that might allow copying". But that doesn't automatically mean that anything difficult to work with is magically DRM protected.
Your question and argument is that DRM is substantially impacting bandwidth, which is patently untrue.With or without DRM, the volume of streaming traffic will be effectively the same. The vast majority of people do not and will not cache content unless their playback/media management system provides that functionality. Streaming is here to stay because it is convenient. Spotify, iTunes Radio, Pandora, etc are destroying the MP3 market the same way iTunes and Amazon MP3s destroyed the CD market. Because the convenience of instantly playing something unplanned and on demand is more desirable than convenience of carrying around a curated library of personal favorites.
Yes, there will always be room and a need for hybrid approaches for streaming vs. local cache, and the market is experimenting with those business models and technology patterns now. But again, the impact is not driven by DRM, but by how people expect to engage with their media.
If they want to, Streaming providers can build ways of allowing offline playback, and still use DRM. Spotfiy does this today.
Instead of complaining about DRM, you should be complaining about Streaming. If my phone can't store a full clip, then whether or not DRM is used has 0 impact on whether or not I stream on each playback or cache it.
Your aggrandizing is not the deep philosophical question you think it is, and there are plenty of examples on how companies have solved your non-issue. Whether or not companies choose to invest and do so is a completely different discussion than "How much bandwidth is wasted by DRM"
In a large organization where its not possible to talk to everyone informally. And if some dev sitting in a corner downloads his/her favorite framework, nobody will know. Until the dependency lists are compared and someone finds out that this person went off on their own.
When that dev breaks the build on the continuous integration and automated test servers, it's pretty easy to point fingers and make them go back and remove their framework and rebuild to the agreed-upon project standards. The framework shouldn't be in your project source control anyways.
Turning over server administration to a DevOps role doesn't require turning over local workstation administration. If it did, no one would ever be able to contribute to open-source projects hosted on Github. And I think they've proven that huge development teams can work together without burdening what goes on with the physical desktop in front of you.
Plenty of content stores allow you to pre-download the content (iTunes comes to mind) and watch at your leisure with or without a data connection. DRM is irrelevant.
The poster is intentionally trying to conflate DRM with Streaming Media.
If your projects can't handle things like dependency lists, package managers, and actual planning, then of course it's going to fall apart like you describe.
I don't know about where you work, but where I work, people actually talk to each other and plan what versions and which frameworks we'll be using rather than just setting everyone off willy-nilly and pray that it all works before being pushed to production.
We have local workstations, dev servers, staging servers, and production.
Devs can do whatever they want on their local workstation. In any given week, I work on 2-3 different projects with radically different stacks. Central IT (which is technically outsourced to a stand-alone company that supports us and the other companies owned by our Fortune-500 overloard) has absolutely 0 knowledge of what we do and what we need to support our work.
Devs also usually have sudo access to the dev servers, but rarely install things there.
Devs never have admin access to staging, but they usually have the ability to do deploys from the build server.
Devs absolutely never have admin access to prod, and can't do deploys to prod either.
Dev team builds, tests and does whatever is needed on local and dev servers. They're responsible to make sure their stuff works and when ready for testing, trigger an automated deploy to stage. They don't have the ability to install any dependencies or configurations on stage, so if they run into problems, they need to negotiate with DevOps. QA validates on stage and has client do UAT on stage. If everything passes, DevOps manages the deploy to production.
That's a grand total of 3 "technical" people on the small project. Dev, QA, DevOps. Large projects will have multiple people in each role, but we still structure the same way.
Why in the hell would anyone be working on production code on their local machine?
We're saying the same thing about Devs and Production environments. But somehow you've extrapolated that into Devs not having admin privileges on their local workstations which is absurd.
If you absolutely don't want to do any administration tasks, that's fine. But its a rare developer who doesn't throw a fit when management takes their admin/root privileges away on their own workstation.
It's legitimate for a developer to throw a fit. They should have admin access on their local box. There's an insane number of plugins, libraries, and frameworks they may need to install or test to determine if it's the right fit for their deliverable.
However, I fully expect DevOps to question every single add on and make the developer justify it before deploying to production. Just because I as a Dev want Ruby for compiling SCSS to CSS on my local machine to save me time, does not mean Ruby needs to be installed on the production environment. That's what build servers and deployment scripts are for.
SysOps on the other hand is far too prone to blanket say "No" or "We only approve this one obscure outdated fork of the package you want."
DevOps is the perfect position to reconcile developer wants with checks and balances against actual needs and responsible deployment.
Your value isn't in being the guru. Gurus get replaced because of the risk in only one person understanding how things work.
Your value is in being proficient enough that you can jump in and get up to speed in different roles, but have a general understanding that lets you step back and see the big picture.
Yes, getting your hands dirty is different pieces is key to this, but being the leading expert in each individual piece is the road to being pigeon-holed.
Because I'm busy solving the client's problems, and I have developers underneath me building databases, front end templates, integration platforms, CMS implementations and the works. I DON'T WANT them patching AWS cloud servers for Heartbleed because THEY SUCK AT IT. Likewise, I don't want an IT guy who just installs patches and walks away. My IT department acts like that, and because of them, I still don't have VMWare and test machines in the office even though they were approved 2-3 months ago.
I want people who can setup Git and Jenkins without handholding or wasting tons of time. I want people who can manage security and system updates. I want people who can figure out and get the right versions of Python, JVM, or NoSQL-DB-of-the-month installed without micromanaging. DevOps is an incredibly valuable role if you find the right people to do it.
Hint: If it requires interfacing with the client, it probably isn't a DevOps task.
We have that in the US as well. It's called witholding, and everyone not self-employed does it. If you don't there's penalties for underpaying come April 15.
The crazy part is that the US still requires everyone to self-report on this at the end of the year, even though they already collected the money. You're also expected to list all other forms of income, deductions, and credits and recalculate your tax burden yourself.
Annual tax review, reassessment, and filing should not be a multi-billion-dollar-a-year industry.
Provision a multi-service line (and pay monthly for their modem/router) - or - Provision an Internet-only line and pay a one-time fee for their modem/router.
I did my research. The modems are different, and the line is provisioned differently. With the multi-service modem (even if I downgraded to internet only) I could setup passthrough and handle things with my own router. With the one-time-fee router, that functionality was blocked. Also, provisioning the line for multi-service and downgrading service to internet-only allowed for higher internet speeds than provisioning the line as internet-only.
So at least on UVerse, there was no option to not pay an equipment rental fee and get their maximum speed service.
We've spent 30 years training people that right-clicking is reserved for secondary extended behaviors, and left-click is for primary interaction.
And either way, I wasn't pointing to the fastest way to shutdown, I was pointing the defacto method of shutdown as encouraged by the interface that's explicitly designed to be intuitive for non-technical users.
Metro is a great concept, but fundamentally broken in its implementation as the vast majority of basic user tasks are overly complex, unintuitive, and don't even follow the standard UI practices introduced as part of Metro. Metro is literally inconsistent with itself.
Why is that popup menu I mentioned in the last step even there? I have yet to see that popup menu UI paradigm appear anywhere else in the Metro launcher UI. It's reminiscent of a secondary right-click menu on the desktop, but appears on primary behavior (tap, left click). Every other icon or menu I tap on takes me to a nested full-screen menu tree, tiles, or row of icons. Why does this one single menu get a floating menu relative to the button location instead?
I know I can rip this all out. I don't because this is a test VM for seeing what my average user sees.
If I perceive this as convoluted, confusing, and horrendously unintuitive, what does the basic non-technical user think? And they are supposedly the people this interface was built for.
Oh, I know. Windows+R, "cmd", enter. Type "shutdown/s"
I wasn't asking the quickest way to shutdown for a power user. I was pointing out the obtuseness of the basic, introductory way of performing a task. You know, the thing that should be the most intuitive, straightforward, process.
I just grabbed that as an example. Of course there are ways to work around the limitation, but the most basic elements of the UI have serious fundamental flaws. Some of these are easily correctable, but still haven't been 16 months and two major releases later.
Overall, I think the *idea* of Metro to be something interesting. A unified interface for both mobile and desktop devices is a cool challenge both from a tech and a design standpoint. It's also a bold direction for a company like Microsoft, especially Microsoft, to attempt.
However, the implementation completely fails. The graphics are great, the fonts, colors, etc, are fairly well thought out. The failure is in not thinking about the ramifications of forcing this interface onto the underlying OS layer that doesn't directly support it. Too many elements rely on older Windows interfaces (some going back as far as WinXP or Win2K). Too many basic user tasks (like shutdown) are hidden far deeper than they should because the interaction designers didn't consider them, and the downstream implementation teams just shoehorned them in wherever they would fit.
As someone who's done a lot of UI work, this is really challenging stuff to get right. What is intuitive is often counter to the aesthetic or the underlying technical behavior. It just amazes me how Microsoft let such a flawed experience ship. Why did they bet so heavily, but not put the resources in place to ensure success? Metro could have been a lifesaver for Microsoft if they had actually executed on it thoroughly instead of the usual approach of slap another UI layer on top of the most commonly used elements but leave everything underneath identical to previous versions.
Let me walk you through the steps as I do them on my test VM (default Win 8.1 install, no added software)
Get the the top level of the Metro UI (I still have not figured out how to do this without hitting the windows key on my keyboard. If you're buried multiple levels deep in something, or running something in desktop mode, there's no intuitive way to do this without a touchscreen)
Move your mouse to the bottom right corner of the screen. A tiny transparent icon will appear in the very bottom corner that only displays while the mouse is in motion. This icon is the traditional "minimize" icon. Pretty intuitive that I should go interact with it to do something not present on the home screen.
Hover over this icon, but don't click or right-click! Even though every other interactive icon that appears in Metro requires clicking to engage. If you click it, it minimizes. If you right-click, some other weird bar pops up from the bottom of the screen. Hover, but don't click.
A row of icons will slide in. Most seem relatively intuitive. Other than the convoluted way to get them onscreen, I have little complaint about their appearance or overall functions (other than the one with the Windows logo which does ABSOLUTELY NOTHING because I'm already in the Metro home screen). Click on the one for settings. Really.... settings?
A new menu comes in, with some pretty useless options for Start, Tiles and Help a ton of empty space, and a row of buttons at the bottom. Oh, and another option under that, which looks like a label but is actually where all the "real" settings are hidden. Ignore that for now and click on the button labeled power.
A popup menu appears, select "shut down". I've gone through 5 distinctly different interface methods just to do a shutdown.
Meanwhile, Metro is trying to give me helpful hints to swipe in from the edge of the screen. These "hints" overlay the actual menus I'm trying to use, and have no way to dismiss. Metro really wants me to try swiping and won't dismiss these unless I follow the instructions, even though I have no touchscreen.
Why is it so difficult to just shutdown? Everyone has been taught for years that you must do safe shutdowns on Windows, so let's undo that all in swoop by making a safe shutdown exceedingly difficult to get to?
Here's another example. On my default install, I have news, stocks, etc on the main screen of Metro. OK, I don't care for it, but I can live with it. But the only application (outside of IE) that gets a tile for launching is Silverlight? Why in the world would Silverlight ever need a launcher? And why would that launcher ever need to be on the default start screen?
Because setting up a working BIND installation is a pain. Sure, there are alternative DNS servers, but BIND is the preferred choice on Linux.
If there was a lot of demand for a click-and-go server and configuration, someone would have written it already. But then again, this is a big part of the Linux mindset. If tool A can be tweaked in a convoluted way to perform task B as a subset of its normal operations, then there's rarely incentive be build a dedicated tool for task B
Now, you need to change the OpenWRT script above to contact the server that has the PHP script, and get the public IP address of the subdomain.
OpenWRT and DD-WRT and Tomato already have DynDNS support built in. No reason to setup a PHP and Apache server behind the router to do this.
You still need a public-facing nameserver somewhere to update the DNS to IP address mapping. That's the key service that DynDNS was providing. Reporting your IP is the easy part.
Dyn.com pushes your IP address info out globally. So if you want a run-your-own replacement, you MUST have a working BIND installation. There's no other way to do it. Dyn.com was running a whole bunch of services that all map back to their BIND servers.
Slashdot Mirror
Wow, I was going to say almost the same thing (even about his argument being tatological) but you summarized it much more elegantly.
It is not DRM that enforces it. In fact, I don't think you understand what DRM is.
If I write a proprietary video player, using a proprietary codec, and I stream you videos that only work in that player, that is not DRM just because I was too lazy to provide you a local caching method.
DRM is not "make it inconvenient for me to use with something else". Digital Rights Management is verifying that playback is appropriately licensed. That's it. A key requirement of any DRM schemes is "make it inconvenient to copy" and "make it inconvenient to play with something else that might allow copying". But that doesn't automatically mean that anything difficult to work with is magically DRM protected.
Your question and argument is that DRM is substantially impacting bandwidth, which is patently untrue.With or without DRM, the volume of streaming traffic will be effectively the same. The vast majority of people do not and will not cache content unless their playback/media management system provides that functionality. Streaming is here to stay because it is convenient. Spotify, iTunes Radio, Pandora, etc are destroying the MP3 market the same way iTunes and Amazon MP3s destroyed the CD market. Because the convenience of instantly playing something unplanned and on demand is more desirable than convenience of carrying around a curated library of personal favorites.
Yes, there will always be room and a need for hybrid approaches for streaming vs. local cache, and the market is experimenting with those business models and technology patterns now. But again, the impact is not driven by DRM, but by how people expect to engage with their media.
You still don't get it.
If they want to, Streaming providers can build ways of allowing offline playback, and still use DRM. Spotfiy does this today.
Instead of complaining about DRM, you should be complaining about Streaming. If my phone can't store a full clip, then whether or not DRM is used has 0 impact on whether or not I stream on each playback or cache it.
Your aggrandizing is not the deep philosophical question you think it is, and there are plenty of examples on how companies have solved your non-issue. Whether or not companies choose to invest and do so is a completely different discussion than "How much bandwidth is wasted by DRM"
Hulu and Netflix use streaming models. Whether or not they use DRM is irrelevant.
iTunes has both DRM and DRM-free content. They operate a model where you download. Both formats work for offline playback.
Amazon also has pay now, consume later content. Again, with and without DRM.
Spotify, which operates on primarily streaming model, offers content for local download and offline playback. Again, DRM doesn't affect this ability.
Your entire premise and argument is flawed because you equate DRM to Streaming.
When that dev breaks the build on the continuous integration and automated test servers, it's pretty easy to point fingers and make them go back and remove their framework and rebuild to the agreed-upon project standards. The framework shouldn't be in your project source control anyways.
Turning over server administration to a DevOps role doesn't require turning over local workstation administration. If it did, no one would ever be able to contribute to open-source projects hosted on Github. And I think they've proven that huge development teams can work together without burdening what goes on with the physical desktop in front of you.
And the premise is wrong.
Plenty of content stores allow you to pre-download the content (iTunes comes to mind) and watch at your leisure with or without a data connection. DRM is irrelevant.
The poster is intentionally trying to conflate DRM with Streaming Media.
If your projects can't handle things like dependency lists, package managers, and actual planning, then of course it's going to fall apart like you describe.
I don't know about where you work, but where I work, people actually talk to each other and plan what versions and which frameworks we'll be using rather than just setting everyone off willy-nilly and pray that it all works before being pushed to production.
We have local workstations, dev servers, staging servers, and production.
Devs can do whatever they want on their local workstation. In any given week, I work on 2-3 different projects with radically different stacks. Central IT (which is technically outsourced to a stand-alone company that supports us and the other companies owned by our Fortune-500 overloard) has absolutely 0 knowledge of what we do and what we need to support our work.
Devs also usually have sudo access to the dev servers, but rarely install things there.
Devs never have admin access to staging, but they usually have the ability to do deploys from the build server.
Devs absolutely never have admin access to prod, and can't do deploys to prod either.
Dev team builds, tests and does whatever is needed on local and dev servers. They're responsible to make sure their stuff works and when ready for testing, trigger an automated deploy to stage. They don't have the ability to install any dependencies or configurations on stage, so if they run into problems, they need to negotiate with DevOps. QA validates on stage and has client do UAT on stage. If everything passes, DevOps manages the deploy to production.
That's a grand total of 3 "technical" people on the small project. Dev, QA, DevOps. Large projects will have multiple people in each role, but we still structure the same way.
Why in the hell would anyone be working on production code on their local machine?
We're saying the same thing about Devs and Production environments. But somehow you've extrapolated that into Devs not having admin privileges on their local workstations which is absurd.
You completely misunderstood what I was saying.
Devs should have admin access *on their local machines* so they can evaluate libraries and platforms.
Devs and DevOps should coordinate and plan to decide which (if any) of those libraries should be included on the production environments.
DevOps should have nothing to do with workstation IT.
It's legitimate for a developer to throw a fit. They should have admin access on their local box. There's an insane number of plugins, libraries, and frameworks they may need to install or test to determine if it's the right fit for their deliverable.
However, I fully expect DevOps to question every single add on and make the developer justify it before deploying to production. Just because I as a Dev want Ruby for compiling SCSS to CSS on my local machine to save me time, does not mean Ruby needs to be installed on the production environment. That's what build servers and deployment scripts are for.
SysOps on the other hand is far too prone to blanket say "No" or "We only approve this one obscure outdated fork of the package you want."
DevOps is the perfect position to reconcile developer wants with checks and balances against actual needs and responsible deployment.
Your value isn't in being the guru. Gurus get replaced because of the risk in only one person understanding how things work.
Your value is in being proficient enough that you can jump in and get up to speed in different roles, but have a general understanding that lets you step back and see the big picture.
Yes, getting your hands dirty is different pieces is key to this, but being the leading expert in each individual piece is the road to being pigeon-holed.
Amen amen!
We have dev ops, and I RESPECT the guys.
Why?
Because I'm busy solving the client's problems, and I have developers underneath me building databases, front end templates, integration platforms, CMS implementations and the works. I DON'T WANT them patching AWS cloud servers for Heartbleed because THEY SUCK AT IT. Likewise, I don't want an IT guy who just installs patches and walks away. My IT department acts like that, and because of them, I still don't have VMWare and test machines in the office even though they were approved 2-3 months ago.
I want people who can setup Git and Jenkins without handholding or wasting tons of time. I want people who can manage security and system updates. I want people who can figure out and get the right versions of Python, JVM, or NoSQL-DB-of-the-month installed without micromanaging. DevOps is an incredibly valuable role if you find the right people to do it.
Hint: If it requires interfacing with the client, it probably isn't a DevOps task.
We have that in the US as well. It's called witholding, and everyone not self-employed does it. If you don't there's penalties for underpaying come April 15.
The crazy part is that the US still requires everyone to self-report on this at the end of the year, even though they already collected the money. You're also expected to list all other forms of income, deductions, and credits and recalculate your tax burden yourself.
Annual tax review, reassessment, and filing should not be a multi-billion-dollar-a-year industry.
I had 2 options when provisioning UVerse.
Provision a multi-service line (and pay monthly for their modem/router) - or - Provision an Internet-only line and pay a one-time fee for their modem/router.
I did my research. The modems are different, and the line is provisioned differently. With the multi-service modem (even if I downgraded to internet only) I could setup passthrough and handle things with my own router. With the one-time-fee router, that functionality was blocked. Also, provisioning the line for multi-service and downgrading service to internet-only allowed for higher internet speeds than provisioning the line as internet-only.
So at least on UVerse, there was no option to not pay an equipment rental fee and get their maximum speed service.
We've spent 30 years training people that right-clicking is reserved for secondary extended behaviors, and left-click is for primary interaction.
And either way, I wasn't pointing to the fastest way to shutdown, I was pointing the defacto method of shutdown as encouraged by the interface that's explicitly designed to be intuitive for non-technical users.
Metro is a great concept, but fundamentally broken in its implementation as the vast majority of basic user tasks are overly complex, unintuitive, and don't even follow the standard UI practices introduced as part of Metro. Metro is literally inconsistent with itself.
Why is that popup menu I mentioned in the last step even there? I have yet to see that popup menu UI paradigm appear anywhere else in the Metro launcher UI. It's reminiscent of a secondary right-click menu on the desktop, but appears on primary behavior (tap, left click). Every other icon or menu I tap on takes me to a nested full-screen menu tree, tiles, or row of icons. Why does this one single menu get a floating menu relative to the button location instead?
I know I can rip this all out. I don't because this is a test VM for seeing what my average user sees.
If I perceive this as convoluted, confusing, and horrendously unintuitive, what does the basic non-technical user think? And they are supposedly the people this interface was built for.
Oh, I know. Windows+R, "cmd", enter. Type "shutdown /s"
I wasn't asking the quickest way to shutdown for a power user. I was pointing out the obtuseness of the basic, introductory way of performing a task. You know, the thing that should be the most intuitive, straightforward, process.
In what way is that remotely intuitive. Really? Ctl-RightMouse on brand logo?
Power-down is not an advanced user task.
And that logo doesn't even exist in Win8. It was reintroduced in 8.1
I just grabbed that as an example. Of course there are ways to work around the limitation, but the most basic elements of the UI have serious fundamental flaws. Some of these are easily correctable, but still haven't been 16 months and two major releases later.
Overall, I think the *idea* of Metro to be something interesting. A unified interface for both mobile and desktop devices is a cool challenge both from a tech and a design standpoint. It's also a bold direction for a company like Microsoft, especially Microsoft, to attempt.
However, the implementation completely fails. The graphics are great, the fonts, colors, etc, are fairly well thought out. The failure is in not thinking about the ramifications of forcing this interface onto the underlying OS layer that doesn't directly support it. Too many elements rely on older Windows interfaces (some going back as far as WinXP or Win2K). Too many basic user tasks (like shutdown) are hidden far deeper than they should because the interaction designers didn't consider them, and the downstream implementation teams just shoehorned them in wherever they would fit.
As someone who's done a lot of UI work, this is really challenging stuff to get right. What is intuitive is often counter to the aesthetic or the underlying technical behavior. It just amazes me how Microsoft let such a flawed experience ship. Why did they bet so heavily, but not put the resources in place to ensure success? Metro could have been a lifesaver for Microsoft if they had actually executed on it thoroughly instead of the usual approach of slap another UI layer on top of the most commonly used elements but leave everything underneath identical to previous versions.
Yeah, vector photographs, those work great!
How do you shut down Windows 8 with a mouse?
Let me walk you through the steps as I do them on my test VM (default Win 8.1 install, no added software)
Get the the top level of the Metro UI (I still have not figured out how to do this without hitting the windows key on my keyboard. If you're buried multiple levels deep in something, or running something in desktop mode, there's no intuitive way to do this without a touchscreen)
Move your mouse to the bottom right corner of the screen. A tiny transparent icon will appear in the very bottom corner that only displays while the mouse is in motion. This icon is the traditional "minimize" icon. Pretty intuitive that I should go interact with it to do something not present on the home screen.
Hover over this icon, but don't click or right-click! Even though every other interactive icon that appears in Metro requires clicking to engage. If you click it, it minimizes. If you right-click, some other weird bar pops up from the bottom of the screen. Hover, but don't click.
A row of icons will slide in. Most seem relatively intuitive. Other than the convoluted way to get them onscreen, I have little complaint about their appearance or overall functions (other than the one with the Windows logo which does ABSOLUTELY NOTHING because I'm already in the Metro home screen). Click on the one for settings. Really.... settings?
A new menu comes in, with some pretty useless options for Start, Tiles and Help a ton of empty space, and a row of buttons at the bottom. Oh, and another option under that, which looks like a label but is actually where all the "real" settings are hidden. Ignore that for now and click on the button labeled power.
A popup menu appears, select "shut down". I've gone through 5 distinctly different interface methods just to do a shutdown.
Meanwhile, Metro is trying to give me helpful hints to swipe in from the edge of the screen. These "hints" overlay the actual menus I'm trying to use, and have no way to dismiss. Metro really wants me to try swiping and won't dismiss these unless I follow the instructions, even though I have no touchscreen.
Why is it so difficult to just shutdown? Everyone has been taught for years that you must do safe shutdowns on Windows, so let's undo that all in swoop by making a safe shutdown exceedingly difficult to get to?
Here's another example. On my default install, I have news, stocks, etc on the main screen of Metro. OK, I don't care for it, but I can live with it. But the only application (outside of IE) that gets a tile for launching is Silverlight? Why in the world would Silverlight ever need a launcher? And why would that launcher ever need to be on the default start screen?
Because setting up a working BIND installation is a pain. Sure, there are alternative DNS servers, but BIND is the preferred choice on Linux.
If there was a lot of demand for a click-and-go server and configuration, someone would have written it already. But then again, this is a big part of the Linux mindset. If tool A can be tweaked in a convoluted way to perform task B as a subset of its normal operations, then there's rarely incentive be build a dedicated tool for task B
OpenWRT and DD-WRT and Tomato already have DynDNS support built in. No reason to setup a PHP and Apache server behind the router to do this.
You still need a public-facing nameserver somewhere to update the DNS to IP address mapping. That's the key service that DynDNS was providing. Reporting your IP is the easy part.
Dyn.com pushes your IP address info out globally. So if you want a run-your-own replacement, you MUST have a working BIND installation. There's no other way to do it. Dyn.com was running a whole bunch of services that all map back to their BIND servers.