That's another thing I won't consider. I want my console to be under manufacturer warrantee, and I have no interest in playing imports, and I'm not a thief.
The only people who will give a shit about backward compatibility are current xbox owners.
Absolutely not true.
I will not buy any console unless there's a large body of cheap used games for it. I just recently bought a GameCube because the used shops are now carrying a bunch of cheap used games. I bought most of my PS1 games after I owned a PS2 (preordered my PS2 before it came out in the US).
I do not yet own an XBox. If the next generation of XBox were to be compatible with first-gen XBox titles, I would probably buy one, and I would probably then go out and buy a metric buttload of old, cheap, used XBox 1 titles. If it's not compatible, I will probably ignore both the XBox and XBox 2, buy a Sony PS3 almost as soon as it comes out, and buy the next generation Nintendo console a few years after it's introduced (assuming Nintendo still has some compelling exclusive content by then).
But if the value of its continued existence in the wild is predicated upon its potentially exploitable commercial value (as the argument goes, not as is necessarily the case), then that isn't something that needs to be stopped, except insofar as exterminating bacteria A may cause us to lose our supply of substance B.
Not true, really. Exterminating bacteria A may cause us to never discover substance C to begin with. It may also cause us to lose species D, which prevents us from discovering substance E.
In other words, you can value its continued existence in the wild on an economic basis without tying it to a single known chemical compound, and you would be wise to. You wanna keep that biodiversity up, and study the bejezis out of it.
If you're going to use the biodiversity for exploitation argument, you can't complain when someone actually starts exploiting.
Yes, we can. It all depends on how people exploit.
If the exploitation is done by taking a small sample of the organism and then figuring out what compounds it produces that are so useful, and why they're so useful, and then reproducing those compounds and/or effects via an industrial process, that's a fine thing.
Even if the exploitation is done by taking a gene sequence from a creature, throwing it on a plasmid, shoving that into a friendly bacterial culture, and growing the shit in a vat, that's a pretty decent thing.
But if the exploitation is done by harvesting enough of the organism to pose a threat to its continued existence in the wild, then that's something that needs to be stopped (or we may have no more Truffula Trees, for example).
Why would you be at any more disadvantage when coding Java without tools vs. C?
Just look at the J2EE stuff. You have to edit like seventy three files, some of which are.java and some of which are XML, and their contents all have to be in sync, just to make a simple bean that does one thing, and god help you if you want it to be exposed as a web service.
When the designers were building the J2EE frameworks, they took for granted that coders would use tools, and it's reflected in the annoying complexities.
If I want to write a daemon in C, I write a simple little command line program that reads from stdin and writes to stdout, and I stick it in inetd. Done.
Personally, I'm a bit appalled that so many bits of Java are so tricky that tools are really needed.
When I code in C, I use Emacs and Make, and I don't think I'm at much of a disadvantage with respect to people who are using C IDEs. In an ideal world, when I code in Java, I'd like to use Emacs and Ant, and I'd like to be at not much of a disadvantage with respect to people using Eclipse and NetBeans.
I actually have high hopes for Java 1.5 in this regard. The whole "metadata" thing could totally revolutionize Java development, making it pretty simple to do fairly complicated things. My hopes are that once that's in place, the tools are much less necessary.
I've been using this trick since I started using eBay, something like six years ago. When you look for something, always look for misspellings first, because you're less likely to have competition. Even got a gemstone or two this way.
It's been known for years, and it hasn't changed much. I don't think this article is going to cause much of a change, even if it's widely read.
Looks vaguely to me like they're trying to put a Blackberry in your TV set. That's a logical thing for the TiVo folks to go after, if so. When I'm in the living room watching TV, it might be nice to be able to check my mail without firing up the laptop, as long as it doesn't involve any hardware or service that I wasn't going to have already (just got a TiVo).
Well, I suppose in some sense it's good to note that some of the items on the list were for the Macintosh. RadioShark, RealPC, there's mac stuff there.
Everything sold as retail software now comes with at least a CD key, if not an activiation system.
Hm. I'm a Macintosh user, and this ain't so for me. As a matter of fact, I just opened a fresh box of iLife '04 yesterday (GarageBand is neat), and there wasn't a CD key anywhere to be found. I could even have installed the software from a disk image, it was just distributed as standard.pkg files. Didn't need a CD key for AppleWorks either.
I can find references to other people who think this, but I can't find anything that actually says it's true. As a matter of fact, I've found sites that debunk this as a myth. I'd love to have concrete info saying otherwise...
I just looked at all those icons, and here's another observation: exactly one of those format icons is available in two variants: with and without a padlock icon to represent the presence or absence of DRM. That's AAC. All of the other icons are only available in the format that indicates "no DRM".
I could sort-of see Apple supporting DRM-free WMA files. That'd let people who've encoded a lot of data into WMA format on their own use that data without re-encoding. I could see that helping to sell iPods (I know someone who's been unwilling to buy one because he didn't want to re-encode all his Ogg files; there are probably more people who've encoded large libraries to WMA than there are who've encoded them to Ogg).
That's pretty interesting. Okay, so WMA isn't the best format for re-encoding de-DRMed compressed data. It's just the best format that's going to be available on the iPod. Are any of those other formats available on small, portable, hard-disk-based players?
It's also interesting to note that while it isn't the best, it also isn't the worst, and there's not a huge difference (they all compress to between 55% and 60% of the original file size).
I guess I don't understand your point, so I'll restate mine in more detail.
If you decode MP3 or AAC and then re-encode into any lossy codec, no matter how good (ie. including ogg), there's some degradation. This is undesirable. (Also, just about nothing will play it; in particular, the iPod -- which this article is about, remember the article? -- won't play it.)
If you don't re-encode, sure, you can play it on an iPod without any loss of quality, but it takes up a huge amount of space. This is undesirable.
If you re-encode to a lossless compression format, you get the best of both worlds -- it takes up less space, and there's no loss of quality. This makes it the perfect format for re-encoding data that's in a DRMed compressed format. You've already lost some quality, but this lets you avoid stacking errors on top of errors.
I sometimes read PDFs on my Handspring Visor. It's a pain. I think PDFs in a handheld will be unpleasant at best until we've got handhelds with better than 150dpi resolution.
We were also using a huge SCSI external CD recorder in 1994. For some reason, "Philips PCD-100" sounds right, but I'm not certain. I was working in a lab at the University of Pittsburgh that focused exclusively on new technologies -- we'd play with them there to figure out if they had any practical applications at the rest of the university. With a university that size, it was worth it to make "just go ahead and buy one and play around with it" a part of the process for evaluating new technologies. It was a great place to work.
It was a big expensive thing, would make coasters over 50% of the time, and consumed all the resources of the Macintosh it was hooked up to (a high-end m68k mac, which was still in practice faster than PowerPC macs in those days) -- to such a degree that if anyone moved a single window during the burn, it would make a coaster. That sucked, because blanks were $15 and up.
But alas, I also cannot remember what software we were using. I do remember the very first time I helped a local band burn an audio CD of their own work. That was a cool day.
But I don't remember what software we used. I do remember that we could do multisession CDs, though many computers could not read the result. (Heck, none of the CD-ROM drives I myself owned at the time, like the original NeXT SCSI CD-ROM drive, could read CD-R media at all. Still have one of the SCSI ones from those days sitting around in an enclosure somewhere.)
Other cool things we played with at that lab: wax transfer printers with PostScript interpreters, a photo quality full page dye sublimation printer (its consumables were strange), postscript printers that printed to 35mm film (amazingly useful for PowerPoint), all manner of video transfer equipment, all manner of scanners, and fairly early web sites (folks were pulling tricks to get specific behaviors out of Mosaic, and had to rebuild them when the first version of Netscape started to get some use).
Anyway, that all reminds me -- before we were doing this stuff in the lab, photo CDs were already available. That was the first place I ever saw the use of CD-R media, and the first place I ever saw multisession CDs. Back in those days, sometimes vendors would refer to the capability of a CD-ROM drive to read multisession CD-R media as "photo CD compatibility". Folks researching prior art on this one should look at how PhotoCD production was done by the places you'd send your film to, back in the days before people could really do it themselves.
A while back, Red Hat acquired the startup company that I was a part of, "Hell's Kitchen Systems". We made closed-source credit card processing software that ran on Linux (and other Unix flavors -- it was called "CCVS").
All the folks from our startup left Red Hat years ago, and nothing has been done with that closed-source CCVS source code for years.
Any chance I could get that source code back? I'd like to take a stab at removing the closed-source bits and releasing an open source credit card processing engine, but as long as Red Hat owns my old proprietary work, the intellectual property issues surrounding this are stopping me from making the attempt. So, could I get it back? Pretty please?
...is the episode of Frekazoid during which he (with his cheeks) explains the motion picture rating system. It also happens to be a 2-parter, the Freakazoid origin story, called "The Chip".
Interestingly, Jack Valenti actually voiced himself in these episodes, so at that time (1995) he apparently still had a sense of humor.
Remember, while they may not enforce it, dumping a DRM'ed tune to CD, and then ripping the CD to MP3, constitutes a DMCA violation.
Not with the iTunes music store, it doesn't. In this case, Apple negotiated explicitly so you would have the right to burn the track to CD an unlimited number of times and then treat it like you would any other CD. With iTMS, this is not a DMCA violation, it's more like a right you're explicitly granted.
What this change means is, every time my contract comes up, I can shop around for the best deal all over again. Since I last got a cell phone, my wife has seen how useful they are. So, now I'm going to shop around for one of those family plans, where calls between two particular phones are free and the two phones share a pool of minutes. Now I don't have to care whether that deal comes from Verizon or someone else. And if I can get a better phone than my old StarTAC, perhaps one that works with iSync, all the better.
If I could not keep my number while switching carriers, there's no way I would even entertain the idea of switching carriers.
I will not buy any console unless there's a large body of cheap used games for it. I just recently bought a GameCube because the used shops are now carrying a bunch of cheap used games. I bought most of my PS1 games after I owned a PS2 (preordered my PS2 before it came out in the US).
I do not yet own an XBox. If the next generation of XBox were to be compatible with first-gen XBox titles, I would probably buy one, and I would probably then go out and buy a metric buttload of old, cheap, used XBox 1 titles. If it's not compatible, I will probably ignore both the XBox and XBox 2, buy a Sony PS3 almost as soon as it comes out, and buy the next generation Nintendo console a few years after it's introduced (assuming Nintendo still has some compelling exclusive content by then).
In other words, you can value its continued existence in the wild on an economic basis without tying it to a single known chemical compound, and you would be wise to. You wanna keep that biodiversity up, and study the bejezis out of it.
If the exploitation is done by taking a small sample of the organism and then figuring out what compounds it produces that are so useful, and why they're so useful, and then reproducing those compounds and/or effects via an industrial process, that's a fine thing.
Even if the exploitation is done by taking a gene sequence from a creature, throwing it on a plasmid, shoving that into a friendly bacterial culture, and growing the shit in a vat, that's a pretty decent thing.
But if the exploitation is done by harvesting enough of the organism to pose a threat to its continued existence in the wild, then that's something that needs to be stopped (or we may have no more Truffula Trees, for example).
When the designers were building the J2EE frameworks, they took for granted that coders would use tools, and it's reflected in the annoying complexities.
If I want to write a daemon in C, I write a simple little command line program that reads from stdin and writes to stdout, and I stick it in inetd. Done.
Personally, I'm a bit appalled that so many bits of Java are so tricky that tools are really needed.
When I code in C, I use Emacs and Make, and I don't think I'm at much of a disadvantage with respect to people who are using C IDEs. In an ideal world, when I code in Java, I'd like to use Emacs and Ant, and I'd like to be at not much of a disadvantage with respect to people using Eclipse and NetBeans.
I actually have high hopes for Java 1.5 in this regard. The whole "metadata" thing could totally revolutionize Java development, making it pretty simple to do fairly complicated things. My hopes are that once that's in place, the tools are much less necessary.
I've been using this trick since I started using eBay, something like six years ago. When you look for something, always look for misspellings first, because you're less likely to have competition. Even got a gemstone or two this way.
It's been known for years, and it hasn't changed much. I don't think this article is going to cause much of a change, even if it's widely read.
Looks vaguely to me like they're trying to put a Blackberry in your TV set. That's a logical thing for the TiVo folks to go after, if so. When I'm in the living room watching TV, it might be nice to be able to check my mail without firing up the laptop, as long as it doesn't involve any hardware or service that I wasn't going to have already (just got a TiVo).
Well, I suppose in some sense it's good to note that some of the items on the list were for the Macintosh. RadioShark, RealPC, there's mac stuff there.
Very interesting observation.
I just looked at all those icons, and here's another observation: exactly one of those format icons is available in two variants: with and without a padlock icon to represent the presence or absence of DRM. That's AAC. All of the other icons are only available in the format that indicates "no DRM".
I could sort-of see Apple supporting DRM-free WMA files. That'd let people who've encoded a lot of data into WMA format on their own use that data without re-encoding. I could see that helping to sell iPods (I know someone who's been unwilling to buy one because he didn't want to re-encode all his Ogg files; there are probably more people who've encoded large libraries to WMA than there are who've encoded them to Ogg).
That's pretty interesting. Okay, so WMA isn't the best format for re-encoding de-DRMed compressed data. It's just the best format that's going to be available on the iPod. Are any of those other formats available on small, portable, hard-disk-based players?
It's also interesting to note that while it isn't the best, it also isn't the worst, and there's not a huge difference (they all compress to between 55% and 60% of the original file size).
I guess I don't understand your point, so I'll restate mine in more detail.
If you decode MP3 or AAC and then re-encode into any lossy codec, no matter how good (ie. including ogg), there's some degradation. This is undesirable. (Also, just about nothing will play it; in particular, the iPod -- which this article is about, remember the article? -- won't play it.)
If you don't re-encode, sure, you can play it on an iPod without any loss of quality, but it takes up a huge amount of space. This is undesirable.
If you re-encode to a lossless compression format, you get the best of both worlds -- it takes up less space, and there's no loss of quality. This makes it the perfect format for re-encoding data that's in a DRMed compressed format. You've already lost some quality, but this lets you avoid stacking errors on top of errors.
Does it make sense now?
I do know one way in which WMA is superior to both MP3 and AAC. There's support for lossless compression in WMA.
Ironically, this makes it the ideal format for recompressing files that you decompressed in order to remove their DRM.
I sometimes read PDFs on my Handspring Visor. It's a pain. I think PDFs in a handheld will be unpleasant at best until we've got handhelds with better than 150dpi resolution.
We were also using a huge SCSI external CD recorder in 1994. For some reason, "Philips PCD-100" sounds right, but I'm not certain. I was working in a lab at the University of Pittsburgh that focused exclusively on new technologies -- we'd play with them there to figure out if they had any practical applications at the rest of the university. With a university that size, it was worth it to make "just go ahead and buy one and play around with it" a part of the process for evaluating new technologies. It was a great place to work.
It was a big expensive thing, would make coasters over 50% of the time, and consumed all the resources of the Macintosh it was hooked up to (a high-end m68k mac, which was still in practice faster than PowerPC macs in those days) -- to such a degree that if anyone moved a single window during the burn, it would make a coaster. That sucked, because blanks were $15 and up.
But alas, I also cannot remember what software we were using. I do remember the very first time I helped a local band burn an audio CD of their own work. That was a cool day.
But I don't remember what software we used. I do remember that we could do multisession CDs, though many computers could not read the result. (Heck, none of the CD-ROM drives I myself owned at the time, like the original NeXT SCSI CD-ROM drive, could read CD-R media at all. Still have one of the SCSI ones from those days sitting around in an enclosure somewhere.)
Other cool things we played with at that lab: wax transfer printers with PostScript interpreters, a photo quality full page dye sublimation printer (its consumables were strange), postscript printers that printed to 35mm film (amazingly useful for PowerPoint), all manner of video transfer equipment, all manner of scanners, and fairly early web sites (folks were pulling tricks to get specific behaviors out of Mosaic, and had to rebuild them when the first version of Netscape started to get some use).
Anyway, that all reminds me -- before we were doing this stuff in the lab, photo CDs were already available. That was the first place I ever saw the use of CD-R media, and the first place I ever saw multisession CDs. Back in those days, sometimes vendors would refer to the capability of a CD-ROM drive to read multisession CD-R media as "photo CD compatibility". Folks researching prior art on this one should look at how PhotoCD production was done by the places you'd send your film to, back in the days before people could really do it themselves.
A while back, Red Hat acquired the startup company that I was a part of, "Hell's Kitchen Systems". We made closed-source credit card processing software that ran on Linux (and other Unix flavors -- it was called "CCVS").
All the folks from our startup left Red Hat years ago, and nothing has been done with that closed-source CCVS source code for years.
Any chance I could get that source code back? I'd like to take a stab at removing the closed-source bits and releasing an open source credit card processing engine, but as long as Red Hat owns my old proprietary work, the intellectual property issues surrounding this are stopping me from making the attempt. So, could I get it back? Pretty please?
...is the episode of Frekazoid during which he (with his cheeks) explains the motion picture rating system. It also happens to be a 2-parter, the Freakazoid origin story, called "The Chip".
Interestingly, Jack Valenti actually voiced himself in these episodes, so at that time (1995) he apparently still had a sense of humor.
Could we get a real SciFi channel while we're at it? Pretty please?
What this change means is, every time my contract comes up, I can shop around for the best deal all over again. Since I last got a cell phone, my wife has seen how useful they are. So, now I'm going to shop around for one of those family plans, where calls between two particular phones are free and the two phones share a pool of minutes. Now I don't have to care whether that deal comes from Verizon or someone else. And if I can get a better phone than my old StarTAC, perhaps one that works with iSync, all the better.
If I could not keep my number while switching carriers, there's no way I would even entertain the idea of switching carriers.