It's MIPS. It very likely won't run a modern Flash. Best you'll get is Flash 6, according to another poster.
However, put Gnash on there, and if Gnash can actually play video, it'll be much faster. I've tested -- windowed Flash uses over 50% of a 2.4 ghz AMD X2. (That's 50% of one core, so not as bad as it sounds -- still, 1.2 ghz.) Fullscreen doesn't play smoothly at all, now that it's actually supported.
Download the same video, play it in mplayer or VLC, and CPU usage doesn't rise above 1% -- maybe 2% fullscreen, if that.
Try the same experiment with a modern codec -- 720p h.264 from Vimeo. Sucks in Flash, even if you deliberately force it not to do any scaling. Smooth as butter in mplayer.
So in this case, I'd blame Adobe -- and YouTube/Google for supporting them -- and not the CPU in question.
Would you rather spend $250 on something you can actually do work on or $130 on something that won't be of any use?
Are you sure it won't be of any use? I've gotten quite a lot of use out of a 32 meg machine with 512 megs of storage -- and it didn't even have a working X, just a somewhat weirdly-sized console.
However, an adapter from DVI to VGA is cheap. An adapter from HDMI to DVI would also be cheap. And if you're carrying around a projector, you've got the space for both, if you do have to daisy-chain them. (If you don't, then your projector really should be using HDMI also, to save space.)
It might run some applications just "fine", i.e. has some small system lag, but if you're using this for simple productivity, you still want a minimal amount of lag, if any.
Lag between what?
It won't lag between keystrokes. It won't lag when closing and opening files. Worst case, it'll lag when switching apps, though I still find that unlikely (there's not really enough local storage to give you much swap) -- so, worst case, I'll put my office suite and email on the Web, and use Firefox tabs.
I hear people at work all the time complaining about the crappy Dell's they use and how they operate slowly, and that's with considerably beefier hardware (in comparison).
And that's probably loaded with a middling-to-bloated Windows OS, with thrice-bloated apps, and quite possibly loaded with spyware to make it even slower, and/or some antivirus/antispyware designed to keep that from happening. Plus whatever your admins have installed...
Remember, machines are currently sold with Vista installed which, by Microsoft's own admission, are only certified as capable of booting the OS.
I browsed the Internet, used IM, email, voice chat, and played games on a 200 mhz machine with 32 megs of RAM and a 2 gig hard drive, on Windows 98. It wasn't fast, but it was the farthest thing in the world from "useless".
I later upgraded it to 128 megs of RAM, and ran Gentoo on it. While I can't say compiles were fast, I could certainly leave one running in the background (reniced to hell) and have it be about as usable.
Now I'm spoiled by no less than 80 gigs of disk and 2 gigs of RAM, and 64-bit processors (most dual-core), on any machine I own. But that doesn't make a less-powerful machine "useless".
I'd buy one in a heartbeat for $150, if it had a decent keyboard.
I don't even care about a particularly large screen -- the main thing that would make this a killer app is ssh, and anything approaching a full-size keyboard is going to be much better than an iPhone.
You won't be able to use two applications concurrently without touching deep into swap
Well, if those two applications are Firefox and OpenOffice.org, probably not.
If they're, say, KWord and Konqueror, maybe.
And I can think of a lot of interesting things I could do on something which just ran Firefox, a decent text editor, and a terminal. Come to think of it, that's actually the full extent of what I use on my current development machine, in terms of "applications" -- a few terminal windows, Firefox, Konqueror (because I'm stubborn), and Kate.
Keep in mind, I would even be happy if it wasn't running modern software at all. I got a lot of utility out of a machine with no GUI at all, in 32 megs of RAM -- it basically ran vim and lynx.
which, I assume, is going to then eat up your flash memory
I don't know of any way to run Linux with a swapfile, though, so I assume that it has some tiny amount of swap space reserved, or none at all. The OOM killer wouldn't be fun, but again, I still doubt you're going to hit that.
Some parties claim that we should meter all connections by the bit.
What I can't find is the bit where you cite that. At all. So who's saying this?
But while we're on the subject:
Firstly, users tell us overwhelmingly that they want charges to be predictable.
Yeah, and I'd like my gas, water, and electric to be predictable, too.
But you know what? They are. If I leave the water running, or the lights on, they'll be high. Otherwise, they'll be low. And it's entirely my responsibility (and under my control) whether this happens.
Secondly, users aren't always in control of the number of bits they download.
Bullshit.
Users may not always have the skills to control it. But this is exactly the same as any other utility -- should I be penalized because I use, say, incandescent light bulbs instead of compact fluorescent, thus drawing more power? I may not have the skills to change a light bulb, or to tell one light bulb from another, after all.
And, in fact, unlike the power in my house, we have much more sophisticated instrumentation for analyzing and interfering with IP traffic.
From one central place in my house, I can, maybe, check how much power the house as a whole is using. If I turned on and off individual devices, I could find out how much they're using. I could probably buy some sort of device to attach to individual outlets, to find how much is being drawn from them.
But from one central place in my house, I can measure precisely how much bandwidth is being used, and what it's being used for. I could even set my own limits and throttles. I could completely block that nightly virus update, if I was skeptical about how much it uses.
And finally, a requirement to charge by the bit could spark a price war.
GOOD! This is what we call "competition".
All Internet providers will compete on the basis of one number, even though there's much more to Internet service than that.
Like what, exactly?
You could cite reliability, or responsiveness, but these can be reduced to numbers, too -- uptime and latency, respectively.
For once, my signature is relevant -- it doesn't matter to me much one way or the other. But why, exactly, is price per bit a bad thing?
Maybe you're poor, or don't have a HD home theater, or whatever.
Well, if you're poor, that pretty much automatically disqualifies you as a potential customer.
At that point, it only becomes a pointless debate about whether it's "fair" for you to get to see it anyway. But it has pretty much zero economic impact.
However, someone using a multi-thousand-dollar camcorder, with the framerate synced to the projector's, and the audio dubbed directly from the source... It won't be as good as a DVD rip later (or Blu-Ray/HD), but if I missed it in our local theater (which only has two screens), yes, it definitely might be worth watching.
While it won't necessarily be as professionally done, keep in mind that telesync is the same process by which actual DVDs are made from a movie reel.
That's not news. It's by design -- BD-J allows you to put executable Java on a Blu-Ray disc, much like HDi allows you to put executable JavaScript on an HD-DVD. The news might be that a dev kit makes it easier than burning a disc...
If BD-J is anything like HDi was, it'll be crushingly limited, compared to what the PS3 can do. You're not really going to get a lot more than Pong and Space Invaders out of it. You'd be much better off developing for PS3 Linux, if you're so determined.
I like bzr -- I honestly couldn't choose between hg and bzr, so I eventually picked it for non-technical reasons (bzr is used by Canonical).
However, if you do go with a distributed system, you may want to take a look at Ditz -- it's an issue tracker which uses flat textfiles as a datastore, with the intent that you'll just check those into whatever version control you're using. That means the opening or closing of an issue is directly tied to a commit.
Which means it will work well with any SCM, but is especially well-suited for a distributed one -- better, I think, than trying to wedge those things into something like Trac.
Fun. You know, since my comment about the "moron", I don't think I've actually made a direct attack. You, on the other hand...
file systems are not an inherently commercial product. FLAC support in a commercial product
So are you going to tell me that OS X isn't an inherently commercial product?
I'm asking for FLAC support in a commercial product. You've got directory hardlinks in a filesystem, which is part of a commercial product.
Because causing you some nerd rage will be fun--it plays WAV, doesn't it? That looks pretty open to me. Lossless, even!
Uncompressed.
Nice, though -- you've proven once again who the troll is. "causing some nerd rage," on purpose, is pretty much the definition of trolling.
And Amazon has no DRM'd music on their music store. None. Zip. Nada.
Which has what to do with Apple?
Never mind the whole issue...
Irrelevant.
Which is, you know, why I said never mind.
It's not wholly irrelevant, of course -- the reason MP3 is a problem, and the reason DRM is a problem, is related to the reason requiring a specific client for a fscking music store is a problem.
But given how rationally you don't approach the core issue here, I'd rather not take you into tangents.
I notice that you didn't answer the question as to whether you buy DRM-free music. I must thus conclude that you don't
I do, in Flac format, and not from Apple or from Amazon. I also sometimes buy CDs, because these can be ripped to Flac.
You are incredibly quick to draw conclusions. That, or you just like to say things like this:
Later posts reveal that you think that your company's product development process is somehow superior to Apple's
Not particularly, especially given:
even though your knowledge of Apple's process is no better than most of Slashdot
However, when we're talking about a particular hypothetical process, which results in at least double the work from sheer bureaucracy, before we even factor in the legitimate processes like testing, I believe something is very wrong with that process.
Call me naive, but I do still think that if it takes ten or twenty times as long to implement a given feature as it takes to write the code to support that feature, something's wrong.
My point wasn't to hold up my own process as superior, just to pick an example of this working. And I am, after all, more familiar with the processes where I work, so it's easier to find an example there.
By this logic, regression tests either were written at the start of time, or don't exist.
No, they're written when a bug is discovered. They are called "regression tests" because the point is to prevent regressions -- which requires that you already know about a bug.
I think there's a decent chance of that, yes. Do you have some reason to believe that the code is bug-free?
Not particularly, although popular open source tends to be less buggy as a rule.
Is there any particular reason to believe it's buggy? Is there something special about Apple's engineers that makes them more likely to find a bug than the Xiph community?
Really? How the fuck do you know that? When they were first added to a file system, nobody wanted that? Please. Get your head out of your ass.
You've made my point pretty effectively, then. Nobody wants FLAC? Really?
Never mind that QuickTime plays open formats, they're just not the open formats you like.
Which ones? Or are you operating under a different definition of "open"?
MP3 isn't DRMed. AAC isn't DRMed. Apple sells DRM-free music on the iTunes Store
And, still, tons of DRM'd music.
Never mind the whole issue of requiring the iTunes client to buy said music, instead of, say, a web browser.
Oh, and MP3 isn't DRM'd, but it is heavily patented. Some AACs are DRM'd, some aren't, and all are heavily patented. That's a problem. It's just a problem that it's convenient for Apple to ignore.
almost certainly outweighs the sales from people who want FLAC or OGG.
First, no one wanted hardlinked directories. Apple used them to do something cool (Time Machine).
Second...
Thus, it's not worth doing.
That's both incredibly capitalistic (nothing is worth doing unless it makes money? Really?) and missing the point -- Jobs did say he would embrace open formats. Actually, no, he said Apple would embrace them.
Not because of zealotry, but because at the very least, un-DRM'd media provides a better user experience. Doesn't that make it worth doing?
But as it turns out, even if we restrict the conversation to DRM, he's not following through.
But it doesn't include tests for a component of the code that doesn't currently exist.
Which makes those not regression tests.
I'm suggesting that it will take time to write a good set of tests for the specific codecs that you propose to add
I'm still missing something here.
A codec is about as simple an interface as you can get -- encoded data in, decoded data out. What would make the Ogg tests different than the AAC tests?
Or are you assuming there would be a number of quirky bugs that Apple would immediately have to fix in the codec itself?
They have a responsibility to the shareholders to perform legal due diligence. That isn't "legal BS", it's doing your job.
A job that is caused by legal BS.
And yes, when people can patent a mathematical function, I call bullshit.
You already identified one hole -- open source ogg decoding is likely very fast. At least some of these codecs do work on iPods, as proven by RockBox.
But you're also assuming that:
Apple doesn't do routine security audits -- or that this one feature would require its own audit.
Apple doesn't have a rigorous regression suite for iTunes. (Note: You specifically said regression suite.)
Apple's code -- or the open source code -- is written so poorly that integrating the two would instantly cause 100 crashers.
That basically leaves legal BS. But at this point, how much damage would they cause? It cost you almost nothing to implement it, and it'll cost you almost nothing to remove it.
I understand that it takes more than prototyping. What I don't understand is why there is such an insane gap between the prototype and the working product.
Another free software pundit with absolutely no clue how quality software is actually developed and tested.
Given that I develop and test software for a living... No, not worth it.
It would take more than 2 hours to work out the document to schedule the testing of the new formats, and that's if they hurried.
Given that the development itself would take less than two hours, this means that sheer bureaucracy is slowing them down 50%, before we even talk about the testing itself -- which is, after all, a good idea.
I would say that shows something very wrong with their process, not something particularly naive about my view of the world.
Slashdot Mirror
Well, MIPS might beat PowerPC, but regardless...
It's MIPS. It very likely won't run a modern Flash. Best you'll get is Flash 6, according to another poster.
However, put Gnash on there, and if Gnash can actually play video, it'll be much faster. I've tested -- windowed Flash uses over 50% of a 2.4 ghz AMD X2. (That's 50% of one core, so not as bad as it sounds -- still, 1.2 ghz.) Fullscreen doesn't play smoothly at all, now that it's actually supported.
Download the same video, play it in mplayer or VLC, and CPU usage doesn't rise above 1% -- maybe 2% fullscreen, if that.
Try the same experiment with a modern codec -- 720p h.264 from Vimeo. Sucks in Flash, even if you deliberately force it not to do any scaling. Smooth as butter in mplayer.
So in this case, I'd blame Adobe -- and YouTube/Google for supporting them -- and not the CPU in question.
Costs 4 times as much, but it's easily 4 times as useful.
Not if it's 4 times as bulky, and 4 times as heavy. 6.2 pounds, and 1.7" thick, makes it a good deal less portable.
Oh, and Vista Home Premium easily brings it back down to 2 times as useful, both in annoyance and in raw performance (or lack thereof).
Does your phone have a bigger keyboard? Or a bigger screen?
Does your phone have USB host mode? How about 802.11? VGA out?
And how much more does your phone cost?
Would you rather spend $250 on something you can actually do work on or $130 on something that won't be of any use?
Are you sure it won't be of any use? I've gotten quite a lot of use out of a 32 meg machine with 512 megs of storage -- and it didn't even have a working X, just a somewhat weirdly-sized console.
However, an adapter from DVI to VGA is cheap. An adapter from HDMI to DVI would also be cheap. And if you're carrying around a projector, you've got the space for both, if you do have to daisy-chain them. (If you don't, then your projector really should be using HDMI also, to save space.)
It might run some applications just "fine", i.e. has some small system lag, but if you're using this for simple productivity, you still want a minimal amount of lag, if any.
Lag between what?
It won't lag between keystrokes. It won't lag when closing and opening files. Worst case, it'll lag when switching apps, though I still find that unlikely (there's not really enough local storage to give you much swap) -- so, worst case, I'll put my office suite and email on the Web, and use Firefox tabs.
I hear people at work all the time complaining about the crappy Dell's they use and how they operate slowly, and that's with considerably beefier hardware (in comparison).
And that's probably loaded with a middling-to-bloated Windows OS, with thrice-bloated apps, and quite possibly loaded with spyware to make it even slower, and/or some antivirus/antispyware designed to keep that from happening. Plus whatever your admins have installed...
Remember, machines are currently sold with Vista installed which, by Microsoft's own admission, are only certified as capable of booting the OS.
I browsed the Internet, used IM, email, voice chat, and played games on a 200 mhz machine with 32 megs of RAM and a 2 gig hard drive, on Windows 98. It wasn't fast, but it was the farthest thing in the world from "useless".
I later upgraded it to 128 megs of RAM, and ran Gentoo on it. While I can't say compiles were fast, I could certainly leave one running in the background (reniced to hell) and have it be about as usable.
Now I'm spoiled by no less than 80 gigs of disk and 2 gigs of RAM, and 64-bit processors (most dual-core), on any machine I own. But that doesn't make a less-powerful machine "useless".
I'd buy one in a heartbeat for $150, if it had a decent keyboard.
I don't even care about a particularly large screen -- the main thing that would make this a killer app is ssh, and anything approaching a full-size keyboard is going to be much better than an iPhone.
You won't be able to use two applications concurrently without touching deep into swap
Well, if those two applications are Firefox and OpenOffice.org, probably not.
If they're, say, KWord and Konqueror, maybe.
And I can think of a lot of interesting things I could do on something which just ran Firefox, a decent text editor, and a terminal. Come to think of it, that's actually the full extent of what I use on my current development machine, in terms of "applications" -- a few terminal windows, Firefox, Konqueror (because I'm stubborn), and Kate.
Keep in mind, I would even be happy if it wasn't running modern software at all. I got a lot of utility out of a machine with no GUI at all, in 32 megs of RAM -- it basically ran vim and lynx.
which, I assume, is going to then eat up your flash memory
I don't know of any way to run Linux with a swapfile, though, so I assume that it has some tiny amount of swap space reserved, or none at all. The OOM killer wouldn't be fun, but again, I still doubt you're going to hit that.
And at $150, that is an impulse buy.
Well, I found this bit:
Some parties claim that we should meter all connections by the bit.
What I can't find is the bit where you cite that. At all. So who's saying this?
But while we're on the subject:
Firstly, users tell us overwhelmingly that they want charges to be predictable.
Yeah, and I'd like my gas, water, and electric to be predictable, too.
But you know what? They are. If I leave the water running, or the lights on, they'll be high. Otherwise, they'll be low. And it's entirely my responsibility (and under my control) whether this happens.
Secondly, users aren't always in control of the number of bits they download.
Bullshit.
Users may not always have the skills to control it. But this is exactly the same as any other utility -- should I be penalized because I use, say, incandescent light bulbs instead of compact fluorescent, thus drawing more power? I may not have the skills to change a light bulb, or to tell one light bulb from another, after all.
And, in fact, unlike the power in my house, we have much more sophisticated instrumentation for analyzing and interfering with IP traffic.
From one central place in my house, I can, maybe, check how much power the house as a whole is using. If I turned on and off individual devices, I could find out how much they're using. I could probably buy some sort of device to attach to individual outlets, to find how much is being drawn from them.
But from one central place in my house, I can measure precisely how much bandwidth is being used, and what it's being used for. I could even set my own limits and throttles. I could completely block that nightly virus update, if I was skeptical about how much it uses.
And finally, a requirement to charge by the bit could spark a price war.
GOOD! This is what we call "competition".
All Internet providers will compete on the basis of one number, even though there's much more to Internet service than that.
Like what, exactly?
You could cite reliability, or responsiveness, but these can be reduced to numbers, too -- uptime and latency, respectively.
For once, my signature is relevant -- it doesn't matter to me much one way or the other. But why, exactly, is price per bit a bad thing?
Maybe you're poor, or don't have a HD home theater, or whatever.
Well, if you're poor, that pretty much automatically disqualifies you as a potential customer.
At that point, it only becomes a pointless debate about whether it's "fair" for you to get to see it anyway. But it has pretty much zero economic impact.
Most kids aren't smart enough to realize that movies are shown in the daytime, too, much cheaper, and much less crowded.
A shakey cam is not worth the bandwidth.
However, someone using a multi-thousand-dollar camcorder, with the framerate synced to the projector's, and the audio dubbed directly from the source... It won't be as good as a DVD rip later (or Blu-Ray/HD), but if I missed it in our local theater (which only has two screens), yes, it definitely might be worth watching.
While it won't necessarily be as professionally done, keep in mind that telesync is the same process by which actual DVDs are made from a movie reel.
I am a customer, and this does reassure me.
It is sad, though, that it has to go through legal first.
That's not news. It's by design -- BD-J allows you to put executable Java on a Blu-Ray disc, much like HDi allows you to put executable JavaScript on an HD-DVD. The news might be that a dev kit makes it easier than burning a disc...
If BD-J is anything like HDi was, it'll be crushingly limited, compared to what the PS3 can do. You're not really going to get a lot more than Pong and Space Invaders out of it. You'd be much better off developing for PS3 Linux, if you're so determined.
I like bzr -- I honestly couldn't choose between hg and bzr, so I eventually picked it for non-technical reasons (bzr is used by Canonical).
However, if you do go with a distributed system, you may want to take a look at Ditz -- it's an issue tracker which uses flat textfiles as a datastore, with the intent that you'll just check those into whatever version control you're using. That means the opening or closing of an issue is directly tied to a commit.
Which means it will work well with any SCM, but is especially well-suited for a distributed one -- better, I think, than trying to wedge those things into something like Trac.
File systems are not the same thing, trollboy
Fun. You know, since my comment about the "moron", I don't think I've actually made a direct attack. You, on the other hand...
file systems are not an inherently commercial product. FLAC support in a commercial product
So are you going to tell me that OS X isn't an inherently commercial product?
I'm asking for FLAC support in a commercial product. You've got directory hardlinks in a filesystem, which is part of a commercial product.
Because causing you some nerd rage will be fun--it plays WAV, doesn't it? That looks pretty open to me. Lossless, even!
Uncompressed.
Nice, though -- you've proven once again who the troll is. "causing some nerd rage," on purpose, is pretty much the definition of trolling.
And Amazon has no DRM'd music on their music store. None. Zip. Nada.
Which has what to do with Apple?
Never mind the whole issue...
Irrelevant.
Which is, you know, why I said never mind.
It's not wholly irrelevant, of course -- the reason MP3 is a problem, and the reason DRM is a problem, is related to the reason requiring a specific client for a fscking music store is a problem.
But given how rationally you don't approach the core issue here, I'd rather not take you into tangents.
I notice that you didn't answer the question as to whether you buy DRM-free music. I must thus conclude that you don't
I do, in Flac format, and not from Apple or from Amazon. I also sometimes buy CDs, because these can be ripped to Flac.
You are incredibly quick to draw conclusions. That, or you just like to say things like this:
you are just a whining little bitch.
Feel better now?
Later posts reveal that you think that your company's product development process is somehow superior to Apple's
Not particularly, especially given:
even though your knowledge of Apple's process is no better than most of Slashdot
However, when we're talking about a particular hypothetical process, which results in at least double the work from sheer bureaucracy, before we even factor in the legitimate processes like testing, I believe something is very wrong with that process.
Call me naive, but I do still think that if it takes ten or twenty times as long to implement a given feature as it takes to write the code to support that feature, something's wrong.
My point wasn't to hold up my own process as superior, just to pick an example of this working. And I am, after all, more familiar with the processes where I work, so it's easier to find an example there.
By this logic, regression tests either were written at the start of time, or don't exist.
No, they're written when a bug is discovered. They are called "regression tests" because the point is to prevent regressions -- which requires that you already know about a bug.
I think there's a decent chance of that, yes. Do you have some reason to believe that the code is bug-free?
Not particularly, although popular open source tends to be less buggy as a rule.
Is there any particular reason to believe it's buggy? Is there something special about Apple's engineers that makes them more likely to find a bug than the Xiph community?
Really? How the fuck do you know that? When they were first added to a file system, nobody wanted that? Please. Get your head out of your ass.
You've made my point pretty effectively, then. Nobody wants FLAC? Really?
Never mind that QuickTime plays open formats, they're just not the open formats you like.
Which ones? Or are you operating under a different definition of "open"?
MP3 isn't DRMed. AAC isn't DRMed. Apple sells DRM-free music on the iTunes Store
And, still, tons of DRM'd music.
Never mind the whole issue of requiring the iTunes client to buy said music, instead of, say, a web browser.
Oh, and MP3 isn't DRM'd, but it is heavily patented. Some AACs are DRM'd, some aren't, and all are heavily patented. That's a problem. It's just a problem that it's convenient for Apple to ignore.
And, just so you know, changing one line in Firefox for Linux and committing it to SVN does not make you a software engineer
No, getting paid to develop many lines of code, every day, makes me a software developer.
And just so you know, we call this an Ad-Hominim.
almost certainly outweighs the sales from people who want FLAC or OGG.
First, no one wanted hardlinked directories. Apple used them to do something cool (Time Machine).
Second...
Thus, it's not worth doing.
That's both incredibly capitalistic (nothing is worth doing unless it makes money? Really?) and missing the point -- Jobs did say he would embrace open formats. Actually, no, he said Apple would embrace them.
Not because of zealotry, but because at the very least, un-DRM'd media provides a better user experience. Doesn't that make it worth doing?
But as it turns out, even if we restrict the conversation to DRM, he's not following through.
But it doesn't include tests for a component of the code that doesn't currently exist.
Which makes those not regression tests.
I'm suggesting that it will take time to write a good set of tests for the specific codecs that you propose to add
I'm still missing something here.
A codec is about as simple an interface as you can get -- encoded data in, decoded data out. What would make the Ogg tests different than the AAC tests?
Or are you assuming there would be a number of quirky bugs that Apple would immediately have to fix in the codec itself?
They have a responsibility to the shareholders to perform legal due diligence. That isn't "legal BS", it's doing your job.
A job that is caused by legal BS.
And yes, when people can patent a mathematical function, I call bullshit.
You already identified one hole -- open source ogg decoding is likely very fast. At least some of these codecs do work on iPods, as proven by RockBox.
But you're also assuming that:
Apple doesn't do routine security audits -- or that this one feature would require its own audit.
Apple doesn't have a rigorous regression suite for iTunes. (Note: You specifically said regression suite.)
Apple's code -- or the open source code -- is written so poorly that integrating the two would instantly cause 100 crashers.
That basically leaves legal BS. But at this point, how much damage would they cause? It cost you almost nothing to implement it, and it'll cost you almost nothing to remove it.
I understand that it takes more than prototyping. What I don't understand is why there is such an insane gap between the prototype and the working product.
Another free software pundit with absolutely no clue how quality software is actually developed and tested.
Given that I develop and test software for a living... No, not worth it.
It would take more than 2 hours to work out the document to schedule the testing of the new formats, and that's if they hurried.
Given that the development itself would take less than two hours, this means that sheer bureaucracy is slowing them down 50%, before we even talk about the testing itself -- which is, after all, a good idea.
I would say that shows something very wrong with their process, not something particularly naive about my view of the world.