...more recent posts
Oh my god this Napster stuff is finally getting good. Here's a quick synopsis of the problem: Napster is filtering out songs based on filename. So people figure they can just come up with a convention to change the filename spellings to defeat the system. Maybe 'Metallica' becomes 'Meta11ica'. Fine. That works. But for it to really work you need everybody to know the system (or else people won't know to search using 'Meta11ica'.) And if everybody knows the system, then Napster knows the system (or they will by the next day) and they just block that too. And here's the solution: the aimster pig(latin) encoder. This is the same pig latin system you learned as a kid. Download the program and it will convert all your mp3 filenames into pig latin. As they explain it: "For example, 'Music' becomes 'usicM', 'Hello' becomes
'elloH', and you can guess what becomes 'uckF ouY, ouY pyS astardsB'."
But how could this work? Wouldn't napster figure this out in like .02 seconds? Well yes, but it might well be illegal for them to do so. This is the great part. Under the DMCA, which by the way is one of the worst laws we have, it is illegal to circumvent any copy protection mechanism, and it doesn't appear to matter how trivial that mechanism is. This is the law used against the open source community (most famously in the DeCSS case, where the DVD region coding was cracked, giving linux users the chance to play DVDs they had purchased on their own systems.) IF napster reverse engineers the "pig latin encoding scheme" they will be in violation of the DMCA. LOL. That's the funniest thing I have ever heard. Bravo.
I know probably this won't work, even though it seems legally sound. I'm not stupid enough to think that the law is the law for people with hundreds of millions of dollars. But still, this is going to make it even more clear just how much money does talk. If you use Napster please think about using this device. Very very cool.
In other napster news, looks like a 21 year old Canadian is taking the obvious route, and is looking to set up a napster server (the open source openNap I'm guessing) somewhere in international waters. Probably Sealand is the only place for that. Good luck. The problem is mostly that even if they can't get your data, they can get you. So you have to stay out of the reach of international law too, and I don't think you can live on sealand.
Oh my god this Napster stuff is finally getting good. Here's a quick synopsis of the problem: Napster is filtering out songs based on filename. So people figure they can just come up with a convention to change the filename spellings to defeat the system. Maybe 'Metallica' becomes 'Meta11ica'. Fine. That works. But for it to really work you need everybody to know the system (or else people won't know to search using 'Meta11ica'.) And if everybody knows the system, then Napster knows the system (or they will by the next day) and they just block that too. And here's the solution: the aimster pig(latin) encoder. This is the same pig latin system you learned as a kid. Download the program and it will convert all your mp3 filenames into pig latin. As they explain it: "For example, 'Music' becomes 'usicM', 'Hello' becomes
'elloH', and you can guess what becomes 'uckF ouY, ouY pyS astardsB'."
But how could this work? Wouldn't napster figure this out in like .02 seconds? Well yes, but it might well be illegal for them to do so. This is the great part. Under the DMCA, which by the way is one of the worst laws we have, it is illegal to circumvent any copy protection mechanism, and it doesn't appear to matter how trivial that mechanism is. This is the law used against the open source community (most famously in the DeCSS case, where the DVD region coding was cracked, giving linux users the chance to play DVDs they had purchased on their own systems.) IF napster reverse engineers the "pig latin encoding scheme" they will be in violation of the DMCA. LOL. That's the funniest thing I have ever heard. Bravo.
I know probably this won't work, even though it seems legally sound. I'm not stupid enough to think that the law is the law for people with hundreds of millions of dollars. But still, this is going to make it even more clear just how much money does talk. If you use Napster please think about using this device. Very very cool.
In other napster news, looks like a 21 year old Canadian is taking the obvious route, and is looking to set up a napster server (the open source openNap I'm guessing) somewhere in international waters. Probably Sealand is the only place for that. Good luck. The problem is mostly that even if they can't get your data, they can get you. So you have to stay out of the reach of international law too, and I don't think you can live on sealand.
Use(net) this to search. Great.
Use(net) this to search. Great.
Broadband2wireless. Yes. I hereby swear to buy any product that will help me live a Verizon-free life. And something like this would be the biggie. Please, please, please, bring this to market quickly in NYC. I'll pay twice their price for what they offer (if it really is 700/kbs up and down.)
Broadband2wireless. Yes. I hereby swear to buy any product that will help me live a Verizon-free life. And something like this would be the biggie. Please, please, please, bring this to market quickly in NYC. I'll pay twice their price for what they offer (if it really is 700/kbs up and down.)
Random shot of the day:
Random shot of the day:
Hmmm. I found a subtle bug last night I have to fix today. I found it because of the link I put up to ftrain (below.) Evidently somebody, we'll call him or her A (a signed in user here, but not me) followed the link to ftrain. Good. So then A shows up in Ftrain's referer logs (browser, ip address, OS, and the URL of the link they followed to get to the page.) The subtle part is that A got to my page from the front page, where my page was showing as having new posts. So A clicked through to my page by clicking on the [posts] which uses the /jim/index.php3?new URL which will print out only the new (to user A) posts on my page. The problem is that someone from ftrain followed the link back in order to check out my page and see who was linking to them. Cool. I'd like that guy (if it was him) to check us out. Unfortunately, he came back in with the /jim/index.php3?new (instead of just /jim/ or just /jim/index.php3) and because he didn't have the cookie there were in effect no new posts for him to read, so the page didn't show anything. D'oh. This is easily fixed. I just have to check if the URL contains ?new (which I look for anyway, of course, so that it can act on the ?new command) and then double check that the user is known. If not, it should just default back to index.php3. Easy. Something like:
if (isset($query_string)) {
if (!isset($dmtreecookie)) {
Location("header:http://www.digitalmediatree.com/jim/")
}
}
The problem, like so much else in this project, is not so much fixing something that is broken. The problem is seeing all the possible ways something might be quietly broken (that is: broken, but still working.) So, I'm sorry to have missed an honored visitor, but I did learn something. I'll have that fixed by later today.
Hmmm. I found a subtle bug last night I have to fix today. I found it because of the link I put up to ftrain (below.) Evidently somebody, we'll call him or her A (a signed in user here, but not me) followed the link to ftrain. Good. So then A shows up in Ftrain's referer logs (browser, ip address, OS, and the URL of the link they followed to get to the page.) The subtle part is that A got to my page from the front page, where my page was showing as having new posts. So A clicked through to my page by clicking on the [posts] which uses the /jim/index.php3?new URL which will print out only the new (to user A) posts on my page. The problem is that someone from ftrain followed the link back in order to check out my page and see who was linking to them. Cool. I'd like that guy (if it was him) to check us out. Unfortunately, he came back in with the /jim/index.php3?new (instead of just /jim/ or just /jim/index.php3) and because he didn't have the cookie there were in effect no new posts for him to read, so the page didn't show anything. D'oh. This is easily fixed. I just have to check if the URL contains ?new (which I look for anyway, of course, so that it can act on the ?new command) and then double check that the user is known. If not, it should just default back to index.php3. Easy. Something like:
if (isset($query_string)) {
if (!isset($dmtreecookie)) {
Location("header:http://www.digitalmediatree.com/jim/")
}
}
The problem, like so much else in this project, is not so much fixing something that is broken. The problem is seeing all the possible ways something might be quietly broken (that is: broken, but still working.) So, I'm sorry to have missed an honored visitor, but I did learn something. I'll have that fixed by later today.