I agree. I realized that the world where Zion lives isn't real as soon as Agent Smith downloaded himself to it at the beginning.
Which means that the entire war between the men and the machines, the humans as batteries stuff, *all* the backstory set up in the first movie, may be fake. All of it. There may be another real story we're going to find out in the last one.
The thing I found most interesting was learning how the Oracle works. She simulates humans to 99.9%+ accuracy. The entire system is set up to simulate humans, to make available the choices that they are expected to make. Neo is The One because he doesn't make the expected choices. He doesn't choose to simply believe in reaity. Zion is a place for those who don't exactly fit prediction to have a place to "escape" to. Neo's real breakthrough is that he's going to escape Zion.
The interesting thing about all this is that the Oracle decides what she wants you to do, and says what needs to be said to get you to do it, based upon her simulation. No point to this observation, I just thought it was interesting.
Not to argue in any way that Sun botched Java, but what I meant is, this implementation is for Java programs. It provides no functionality for programs not written in Java. Even if Sun had done Java correctly, my statement would still be true - this isn't a generic implementation, as it requires the code be written in Java. Even if Java itself were generic, this implementation wouldn't be generic, it'd be Java-specific.
When I said "generic implementation" I meant "an implementation which doesn't require your programs be written in a particular language." Which is probably a bit of a pipe dream, you'd still need some sort of glue code (ODBC, JDBC, DBD, etc). But, as was alluded to above, I was trying to beat the Beowulf comment when I asked my question.;)
Just started looking at the site. I've wanted this for years. I was ecstatic with what load-balancing cheap Apache boxes did for the cost of web hosting. Unfortunately, reliability has still required hundreds of thousands of dollars of high-end equipement and software for databases. I've been hoping the open-source community would make headway on this front.
So, the question is - is anyone working on anything like this for Perl, C, or generic implmentations?
That's not actually necessarily true, they could file a lawsuit against "John Doe" and then get a subpoena to force Verizon to tell the court who the John Doe is so they can serve papers on him.
I haven't actually read the Verizon case (and so could be very wrong) but I've always assumed that they're trying for the middle ground of being able to send formal cease-and-desist letters to the users instead of having to file actual lawsuits to get names and addresses.
There's also an important quirk of the law, here. The DMCA makes it pretty clear that, for the big awards, the violations need to be "willful," which means that you knew you were breaking the law when you did it. Proving willfullness is notoriously difficult - this is a case where ignorance of the law is an excuse, and most people can plausibly claim that they had no idea that they were breaking the law. Unless, of course, you got a cease-and-desist letter from the RIAA telling you it was illegal...
If the cease-and-desist letters are then ignored, the RIAA would then obviously have the option of formally filing suit. But, I believe, even if they lose the Verizon case, the RIAA can still sue the sharers as "John Doe" defendents and probably get the court to force Verizon to give the information up, anyway, in that context.
It's going to be interesting to see how this plays out. I've been predicting this phase for years. As on a lot of other things ($.99 major-label downloads) I was a bit ahead of the curve, but I think this is an inevitable development. Copyright law pretty clearly shows that what the users are doing by sharing is illegal. Napster and the first round of p2p were easy to shut down because they ran services, and were clearly complicit in the legal violations. The next round, as the RIAA is finding, are decentralized enough that they can reasonably claim they have no check on their users' behaviors, which means that the creation of those tools is not a violation of the law.
That doesn't, of course, eliminate the problem that what users are doing is a clear violation of copyright law. And not just the much-hated DMCA; what users do under Naptser would've been perfectly illegal in 1992 (albeit the penalties would've been insignificant since it was not-for-profit). The big change in the DMCA was to make it clear that violating copyrights even when you didn't personally profit from it was still something you could get a big damage on.
Anyway, I've been saying for years that the RIAA's attacks against providers were going to run out and the were going to have to go after individual users. If they have the stomach for it, that'll solve the problem - after a few dozen people declare bankruptcy after receiving multi-million dollar damage awards, people will really begin to understand that when they share music, they're breaking the law, and they're not anonymous.
The real question mark in all of this is what the political ramifications of this will be. Will there be enough public outcry to decriminalize the sharing of music? Personally I doubt it; there is too much money arrayed on the other side, and the long history of copyright in this country is an expansion of copyright. It's hard for me to imagine it going the other way.
One way or another, though, this is finally moving to endgame. I see three possible outcomes:
1) The RIAA fails to have the backbone to prosecute individual end-users. If this happens, the world as we know it today will exist indefinitely - lots of bluster from the RIAA and MPAA while users continue to ignore the law. This is the least likely outcome, in my opinion.
2) The RIAA actually sues people and wins. Enourmous public outcry forces Congress to revisit the issue. Despite heavy lobbying from entertainment (and software!) interests, the portions of the DMCA that made not-for-profit distribution of copyrighted material punishable by large cash fines is rolled back, effectively decriminalizing fil
Theoretically possible. But they'd have to get you to encrypt arbitrary chosen-plaintext, and a lot of it, to check the timings. It's probably easier just to root the box and steal your password with a keyboard sniffer.
As long as we're talking dream keyboards, gimme an OmniKey/101. It's easily programmable to change repeat speeds, to a Dvorak layout, etc., through DIP switches. \ where it belongs, ~ where it belongs, / where it belongs. Solid, perfect key action.
Unfortunately I think they were like $120 new and they aren't made, anymore. Friend of mine found some, reconditioned about five years ago, and I bought 4 - one for work, one for home, one for my wife, and one for spare. Wife now uses a laptop, but the work and home one have never given me a lick of trouble.
And, on the original post, I'll grant him scroll lock. But no bash poweruser could get by without the backtick...
OK, so it's 45 million, not 4.5 million. And I did use a calculator, I just didn't count the digits, properly. You can decide if that's worse than simply guessing wrong.:) Which does give a bit more room, but still, if I were designing it for that, I'd give more wiggle room.
Anyway, I think you already know that I'm not saying the RIAA has our best interest at heart. I just think they're already tracking this stuff, anyway, and I know I wish I'd had GRid back at EMusic, and I wasn't trying to track individual tracks. Even though ours were MP3s and actually would be downloaded and traded, unlike their DRM stuff.;)
We're reaching the end of any useful information either of us might have on this, I suspect. The size of the ID field doesn't make me suspicious in and of itself. Numbers are cheap, especially numbers the customer doesn't have to punch in. If there has been one lesson we've seen over and over again in the computer industry, it's that arbitrary limits tend to be eventually overflowed, so it makes sense to make ridiculously large systems. It may also be that an unstated design goal is to allow organizations to "waste" big chunks of it - for example, Sony might want the first four digits of its codes to be SONY so it'd be obvious whose albums it is. That seriously degrades the namespace. You could see similar idea for having sub-divisions, record labels, genres, etc. within a company be assigned their own namespaces. This would allow a major label to distribute the allocation of number to their subsidiaries and not need to control it centrally, but doing this to any level would significantly reduce the numbers available to any one subsidiary.
When I said GRid is "useless" for centralized tracking, I may have overstated, a bit. But, my point was, if you want to centrally track downloads based on some key, it would make sense to give each song (not each sale) some unique number. Then you'd just have to look up in a database of 400,000 IDs. If you give each sale a unique ID, and the whole ~900 million-unit US CD market went online, you'd have to look up against an additional 10 billion items per year.
If I were trying to design a system that would both function as a UPC and track individual sales, I'd've put a seperate field for track identifier and sale identifier.
Now, it is true that any label could arbitrarily decide that "the last five digits are a transaction code." But, I think, in this case, the thing borders on not being big enough. If you make it five digits each for the transaction ID and the track ID, that's only 4.5 million, each. There are certainly albums that sell more than 4.5 million copies. But, if you make it six and four, respectively, that makes the transaction ID space big enough, but you can't have more than 1.3 million items in your catelog, which is certainly within an order of magnitude of the biggest catelogs out there. If this system were designed to track albums and transactions in an easily parsable way, I'd expect this field to be more like 16 digits - and why not make it bigger? Numbers, as I've said, are cheap.
Additionally, if a label makes this arbitrary decision, that means that only the label can track the items out there. I'd think it would be desirable to make it easy for third parties to report pirated music, and if you were designing such a system, you'd want to make it what information was the same for every song and what information was different for every sale.
Anyway, bottom line, I agree with you that the record labels want to do this. In fact, I think they already do, for the limited, lame downloadable offerings they have. If that annoys you, you should be annoyed about that, not about GRid. GRid seems to me to be less than ideally designed to solve the individual sales tracking problem, and definitely does solve the UPC problem. If GRid is for tracking individual sales, it doesn't let them do anything they're not doing, already.
PS: There is one other point that has occured to me - this may be a distraction. They may very quietly announce GRid 2.0 in six months that will be well-designed to track individual sales, and figure no one will notice. That'll be interesting to keep an eye on.
Believe me, I'm not astroturfing. You may disagree with me, but I'm no shill for the record companies. EMusic sided with the RIAA on issues where we thought they were basically correct (i.e., straightforward copyright) and fought them hard when we thought they were wrong (i.e., we filed an amicus brief on Diamond's side in the Rio case). EMusic never joined the RIAA, and the executives while I was there (including myself) were active in causes like the EFF, and opposing the anti-circumvention aspects of the DMCA. I should probably also take this opportunity to reiterate that I no longer work for EMusic. In fact, I'm not involved in the music business in any way at this time, and don't expect to be involved with it directly again in the future. God willing.:)
I'll certainly admit, when I wrote my response, I'd only read the Reuters article. I've now read the bit of documentation the IFPI has put up, and I remain confident that this is intended to be a UPC-like system, not some centralized tracking of who purchased what. The GRid number looks like: A1-123AB-ABC1234567-X. The A1 is always "A1," it means it's a GRid and not something else. The 123AB is the unique ID for each record company, distributor or retailer. The ABC1234567 is the thing which defines the "release." The X is a checksum (although why such is necessary in an online-only number is unclear to me).
The section which is presumably causing everyone to think this is a tracking system is the long one, the "IP Bundle Number." If this were for tracking, I think there would be one field to identify the transaction, and one to identify the underlying recording. If this is for individual tracking, it is useless for centralized tracking of what songs are being swapped.
I believe that you are interpreting the quotes above in the worst possible context. When Mr. Jessop speaks of "sale, licensing and tracking activities," I believe what he means is, "we license this recording to a distributor and we need to have a centralized way to track how many are sold," not "...a centralized way to track who they were sold to."
They don't need GRid to watermark songs uniquely. As I said, they could just stick a big number in the track. Frankly, the little bit of dabbling in downloadable music the majors have done - all with DRM crap no one wants, which is why no one buys it - generally have already have individual tracking built in, intrinsically. PressPlay, for example, the service from Universal and Sony that people are staying away from in droves, encrypts the music to a key on your system. I don't know for sure, but it's difficult for me to imagine that, given such a file, PressPlay couldn't figure out who it was sold to.
Are they building that info into a watermark, too? Sure, they might be. Who knows? Should we be concerned about that? Absolutely, again with the proviso that no one is buying their downloadable music anyway, since it's such a pain - it's nonportable and you're stuck with their software. But they don't need GRid to track individual purchases - they're doing that, already. They need GRid to easily aggregate purchase tracking. Which isn't very scary to me.
Inserting per-purchase tracking info into songs is something to worry about. But I don't think this is necessary for them to do so. The $250/year is comparable to what UCC charges for UPCs - they've just moved to an annual fee structure, and it runs $150 - $9,000 depending how many numbers you need. In fact, on a per-number basis, the RIAA is probably a lot cheaper.
Also, it's worth noting that I doubt they'll "sell millions of IDs per year." The design of IDs like this aren't that the merchant makes them - merchants will get the numbers from the record companies. The RIAA will tell a record company or destributor, "Your prefix is 12345" and this is a 16-digit number, you can make up everything after 12345." The record company or distributor will tell the merchant, "every time you sell this song, put a tick mark next to 1234567890123456 and tell us once a quarter how many you sold." This makes merchant's lives easier because they have unique identifiers for everything in thier system, and it makes it a lot easier to do stuff like figure out top-40 rankings across multiple distributors since everything has a unique string.
If this seems to contradict anything I said in my previous post, please remember that EMusic is unusual in this model - they are a retailer, but, under the covers, they're a music distributor. They license the music they have from artists, and have the ability to re-license it to others. So, in that sense, they're more like a distribution company, and need their own UPCs (or GRips or whatever). When people like Tower think about doing downloadable music, they'll still need a license (that's the law) but they're not thinking redistribution, so they'll be getting this magic number from the licensor.
Again, bottom line, I think that imbedding a unique tag in songs is something some people would like to do, and it's something to keep our eyes open for. But I don't believe this is to do anything except literally to be an online UPC - to give each unique type of item a globally unique identifier. Certainly anyone selling downloadable music could imbed a unique transaction cookie now. Numbers are cheap, you don't have to pay the RIAA to give them to you. Anyone wanting to track individual downloable sales now could put a unique 128-bit cookie into a song and sleep well knowing there'd never be a collision.
No, this is a legitimate issue. I was VP of Technology for EMusic prior to their purchase by Universal. We licensed our MP3s to other resellers. We had at least 125,000 tracks when I left.
We tried to use actual UPCs, but they are only 12 digits. 6 Are the manufacturer ID, 1 is the classs of the item and 1 is a checksum. That only leaves 4 digits for the SKU - only about 10,000 items. We called UCC (the UPC equivilant of ICANN) and asked for 400,000 numbers, because we figured that would cover something like 90% of the music sold in the US. UCC said, "You realize, if you have a bin of screws, you don't put an individual UPC on every screw, you just assign a number to the bin, right?" We explained that we knew that, and that we really did expect to have 400,000 individual, unique items for sale. They said, "We don't think UPC is the solution for you." So we made up our own SKUs, and gave those to our licensees.
Remember that you need one for the album and one for each song - an an average of 13 per album. Every format you provide that in gives you another set of numbers. So, for example, if EMusic wanted to license its 150,000 song catalog in 128kbps MP3, 256kpbs MP3 and Windows Media, in songs and albums, it'd need nearly 500,000 numbers. And EMusic isn't very big, in music terms. If they need half a million, it's very easy to imagine someone really big might need millions. As all programmers know, you should figure out what the maximum amount you could every possibly need and then increase it by at least an order of magnitude.;) If we'd hit our goal of 400,000 songs, that would've been 1.3 million in the above formats.
No, seriously. Process creation under Linux was time-similar to thread creation on other OSs. That's because Linux was as fast at creating *a process* as other OSs are at creating *a thread*. IIRC, threading was initially implemented in Linux from the process-creation methods, so it was similar in speed (the main advantage in Linux from threads was the shared memory space if your application wanted that sort of thing). That's why Apache 2.0 is bringing NT performance more in line with Linux 1.3 performance: NT's threading speed is a lot closer to Linux's forking speed. Again, I'd like to underscore I'm not an expert on this, and it's possible I'm mistaken about relative benchmarks (is NT w/Apache 2.0 a little faster than Linux w/Apache 1.3? Could be...) but I'm very confident of the basic underlying point, that Linux process creation is essentially comparable to other OSs' thread creation, perhaps even faster.
See, for example, http://www.linux.cu/pipermail/linux-prog/2001-Febr uary/000027.html, just one of the first Google links that popped up when I went looking for proof that I'm not on crack: "Linux newcomers often are unaware of the substantial differences between Linux and other operating systems. To implement concurrency, they use multithreading exclusively, mistakenly assuming as high an overhead associated with Linux multiprocessing as on other platforms." In fact, knowing how fast Linux's process creation is relative to other systems' thread creation makes this even more impressive in my mind. This isn't just a bug fix; much like with process creation before it, Linux is doing something fundamentally better than its counterparts.
Don't forget: Just because this is/. doesn't mean I'm just a Windows-hating troll. I try to make sure all my Windows-hating-troll-posts are at least backed up by facts.;)
This could be huge for things like webservers, though, which spend a lot of their time kicking off new (logical) processes. As I understand it, on Linux, a big part of the reason Apache 2.0 hasn't taken off (aside from lack of availability of major packages) is that Apache 2.0's main win is in threading support. Under Linux, thread creation hasn't been much faster than process creation, because process creation was so dang fast.
So, am I right in thinking this means threading (and hence Apache 2.0) will be a big win for Linux web servers, now?
Actually, it looks like they fixed the fax law in California, too. The fax law he signed basically undoes the CA fax law (which was awful), which replaces it with the Federal version (which is tougher).
I wish I could find some details on the penalties for the phone spam law, though. I currently get about one phone spam a month (usually at 4am, of course).
Interesting question: If they spam my phone's email address, can I get them for the anti-phone-message violation even though spam isn't prohibited? If so, it might be worth getting a throwaway phone just to go after the spammers...
I think the real value would lie in location-targeted ads. Just getting money from another "click the money" worthless banner pool probably wouldn't even be worth the trouble. But think how much value targeted advertising would be to local businesses - you can give them people who are literally right next door.
WinAmp and MusicMatch will do just fine. Note there is a "patent only" option at $50,000 flat-rate. As much as AOL paid for WinAmp, they should have no problem paying 50 grand to keep the doors open (and in fact probably already have a licensing deal in place with Fraunhofer that covers WinAmp). Ditto MusicMatch.
Who this kills is the free (as in speech) players - Zinf, XMMS, etc. They can't afford $50k OR $0.75/copy. They can either hope Fraunhofer doesn't notice them, or try to relocate to a place with either no software patents or no Fraunhofer patent, or they can leave MP3. In fact, Linux users in general may be left out in the cold, because I'm not aware of any commercial MP3 decoders for Linux, at all.
Unfortunately, this probably won't be enough to move the world from MP3s. WinAmp will still be downloadable for free, which is all 98% of users care about.
I remember when I was at EMusic, I met with the Thompson guys, who were trying to figure out how to make money on this (circa 1999). I explained to them that nobody was going to pay for a decoder, and that their choice was either to give the decoder away or have people switch to something else. I also suggested the encoder should be free for non-commercial use, in order to cement their current dominance against (then soon-to-be-released) Windows Media.
One of them replied (imagine a German accent), "I see! Vee give avay evrysing for free, and you make more money selling music!"
So, you could say we had a meeting of the minds.:)
Re:What a crappy review (spoilers rot13d)
on
Minority Report
·
· Score: 2
Yes, I did. Sorry, what can I say - I wrote it on STDIN to my codec with limited editing abilities.:)
Re:Leftist Propaganda **SPOILERS**
on
Minority Report
·
· Score: 2
Remember: Anderton doesn't know his son is dead. He presumes - remember, he asks Crowe is Sean is still alive. If he's seeing all his dreams come true, I'd imagine in addition to dreaming that he moves back in with Lara, he'd dream that one day the doorbell rings and it's his 12-year-old son who escaped from his kidnapper. He doesn't need to modify his memories or anything like that.
So, I don't agree, but I think it was a very original and clever thought.
Re:What a crappy review (spoilers rot13d)
on
Minority Report
·
· Score: 2
After writing a quick rot13 codec, I take issue with your second plot hole. Specifically:
Gur ragrejvavat bs gur benpyr naq vgf pyvrag vf n pynffvp bs nyy svpgvba vaibyivat benpyrf. Frr, sbe rknzcyr, Brqvchf Erk, va juvpu gur benpyr'f cerpvpgvba gung Brqvchf jbhyq zneel uvf zbgure naq xvyy uvf sngure vf jung xvpxf bss gur riragf gung yrnq shsvyyvat gur benpyr'f cerqvpgvba. Frr nyfb gur benpyr va gur Zngevp, jub trg Arb gb oernx fbzrguvat va ure xvgpura ol cerqvpgvat ur'yy oernx vg. Jbhyq fhpu guvatf unccra jvgu n "erny" benpyr? Jub xabjf? Ohg univat gur cerpbtf frg va zbgvba va gur riragf gung yrnq Naqregba gb gur cbvag jurer ur'f ubyqvat n tha ba Pebjr vfa'g n cybg-ubyr; vg'f n shaqnzragny nffhzcgvba bs gur pbafgehpg bs na benpyr nf gurl unir vzcyrzragrq vg. Lrf, lbh pbhyq pbaprvir bs na benpyr gung qvqa'g vavgvngr frys-shysvyyvat cebcurpvrf. Ohg Fcvryoret naq Pb. unfa'g pbzr hc jvgu fbzrguvat cnegvphyneyl rtertvbhf jvgu guvf, naq fbzr zvtug nethr gung va snpg gur ersyrpgvba vg pnhfrf ba guvf frrzvat cnenqbk vf va snpg bar bs gur fgeratguf bs gur cybg, abg n jrnxarff.
Re:Leftist Propaganda **SPOILERS**
on
Minority Report
·
· Score: 2
Interesting idea - except that, I think, if it were Anderton's made-up world, he'd have Sean back in it.
I thought that quote in the story about the back button was a little bizarre. "I loaded this page, and it popped up these windows. Then I loaded this page again and it popped them up again!"
I remember I was working at PGP when those cards first really hit. Obviously there were a lot of people there who thought about privacy.:) I remember someone there (heck, might even have been me) had the idea that, much like the "cypherpunks" login with the "cypherpunks" password (which, if you didn't know, is registered in many "registration only" sites, allowing you to login without actually bothering to register), we needed a cypherpunks phone number at Safeway. That way, we could say, "650-555-1212" and get the 5% discount. For those of you who don't know about Safeway, you can enter your phone number as a "key" to get the discount. You can also tell the clerk your phone number, if you're too stupid to type it on the pad, and I've always enjoyed being there at 2AM and seeing the tall, leggy blonde announce her phone number for all to hear.
I then started thinking about the reports that computer was going spit out, because the vast majority of people who would do that are male programmer types (with a handful of women). "Bob! Look at this guy! Last week he purchased 372 liters of Mountain Dew, 27 frozen pizzas, 39 copies of Playboy and one box of Maxi Pads!"
During this time I militantly refused to get such a card and give up my privacy for something as minor as a 5% discount. However, my wife went ahead and applied, but somehow managed to get our phone number wrong. I remember at one point I was buying some beer that was like $2 off per six pack, or something ridiculous. At that time, they were really pushing the cards, and, unless you were willing to be very rude, you got in this catch-22, where, if you told the clerks you didn't have a card, they'd hassle you about how stupid you were being for not saving $6 on the 3 six packs you were buying, or, if you said you left your card at home, they'd hassle you about giving them your phone number.
Anyway, this clerk asked me if I had a card. "Yes, but it's not with me." She wanted to know the number. I gave her my number (obfuscated for this story as 650-555-3940). She punched it in, no such account. She said, "Let me try another one, maybe someone typod it." She typed a number, and the discount popped up. "Good call," said. "What was the number?" "650-555-3949," she said. "Are you Mr. Ngzrschy?" "Nope!" I said. "Thanks!"
Ever since then I've used that number. The name is very difficult to pronounce, and the clerks usually try it one way, then another, then ask, "Did I get that name right?" I always say, "Absolutely!"
Quite specifically (I've been there and done that) what you must do is certify under penalty of perjury that either the supposed copyright owner is mistaken, and you do have the right to distribute the content, or that the owner is mistaken and you never did distribute the content. Once you do that, your ISP is indemnified and may (but doesn't have to) put your site back up. At that point, the copyright-holder can sue you, at which point I believe the ISP has to take you back down until the suit is resolved (although I'm not 100% sure on that as I've never taken a case that far, personally).
But, yes, you're right, for many providers, once you get involved in the process at all, you're not worth the time and money.
And I agree that it is one of the more sensical parts of the DMCA - it gives the ISP a positive defense and sets out pretty clearly the legal path everyone can use to avoid prosecution.
Also, there is no getting around the legal problem. The DMCA is written such that anyone that provides bits to you is an ISP, and they can be provided notice of your copyright violations. Once they receive that notice, they must either remove the content (i.e., by getting you to do it via threats, or by cutting off your service), or they are held legally responsible. Since you probably pay them thousands of dollars a year at most, and willfull copyright violation is $25,000 per occurance, your ISP will not back you, and will pull the plug, because it's not worth the risk.
Theoretically, I suppose, you could be a backbone provider and not have anyone upstream. But unless you're planning on buying Sprint or something, you will have to deal with the fact that there is someone upstream who can pull the plug on you solely because your content has been complained about by a copyright owner.
Also, realistically, every provider has some terms of service. Some of them no one on/. would disagree with (preventing spamming, for example), but many of them there might be some controversy (prohibiting un-PC speech). Again, you're not going to be able to avoid these unless you become a backbone provider. Which is probably a bit over your budget;).
Slashdot Mirror
Spoilers continue, of course...
I agree. I realized that the world where Zion lives isn't real as soon as Agent Smith downloaded himself to it at the beginning.
Which means that the entire war between the men and the machines, the humans as batteries stuff, *all* the backstory set up in the first movie, may be fake. All of it. There may be another real story we're going to find out in the last one.
The thing I found most interesting was learning how the Oracle works. She simulates humans to 99.9%+ accuracy. The entire system is set up to simulate humans, to make available the choices that they are expected to make. Neo is The One because he doesn't make the expected choices. He doesn't choose to simply believe in reaity. Zion is a place for those who don't exactly fit prediction to have a place to "escape" to. Neo's real breakthrough is that he's going to escape Zion.
The interesting thing about all this is that the Oracle decides what she wants you to do, and says what needs to be said to get you to do it, based upon her simulation. No point to this observation, I just thought it was interesting.
Not to argue in any way that Sun botched Java, but what I meant is, this implementation is for Java programs. It provides no functionality for programs not written in Java. Even if Sun had done Java correctly, my statement would still be true - this isn't a generic implementation, as it requires the code be written in Java. Even if Java itself were generic, this implementation wouldn't be generic, it'd be Java-specific.
;)
When I said "generic implementation" I meant "an implementation which doesn't require your programs be written in a particular language." Which is probably a bit of a pipe dream, you'd still need some sort of glue code (ODBC, JDBC, DBD, etc). But, as was alluded to above, I was trying to beat the Beowulf comment when I asked my question.
Just started looking at the site. I've wanted this for years. I was ecstatic with what load-balancing cheap Apache boxes did for the cost of web hosting. Unfortunately, reliability has still required hundreds of thousands of dollars of high-end equipement and software for databases. I've been hoping the open-source community would make headway on this front.
So, the question is - is anyone working on anything like this for Perl, C, or generic implmentations?
That's not actually necessarily true, they could file a lawsuit against "John Doe" and then get a subpoena to force Verizon to tell the court who the John Doe is so they can serve papers on him.
I haven't actually read the Verizon case (and so could be very wrong) but I've always assumed that they're trying for the middle ground of being able to send formal cease-and-desist letters to the users instead of having to file actual lawsuits to get names and addresses.
There's also an important quirk of the law, here. The DMCA makes it pretty clear that, for the big awards, the violations need to be "willful," which means that you knew you were breaking the law when you did it. Proving willfullness is notoriously difficult - this is a case where ignorance of the law is an excuse, and most people can plausibly claim that they had no idea that they were breaking the law. Unless, of course, you got a cease-and-desist letter from the RIAA telling you it was illegal...
If the cease-and-desist letters are then ignored, the RIAA would then obviously have the option of formally filing suit. But, I believe, even if they lose the Verizon case, the RIAA can still sue the sharers as "John Doe" defendents and probably get the court to force Verizon to give the information up, anyway, in that context.
It's going to be interesting to see how this plays out. I've been predicting this phase for years. As on a lot of other things ($.99 major-label downloads) I was a bit ahead of the curve, but I think this is an inevitable development. Copyright law pretty clearly shows that what the users are doing by sharing is illegal. Napster and the first round of p2p were easy to shut down because they ran services, and were clearly complicit in the legal violations. The next round, as the RIAA is finding, are decentralized enough that they can reasonably claim they have no check on their users' behaviors, which means that the creation of those tools is not a violation of the law.
That doesn't, of course, eliminate the problem that what users are doing is a clear violation of copyright law. And not just the much-hated DMCA; what users do under Naptser would've been perfectly illegal in 1992 (albeit the penalties would've been insignificant since it was not-for-profit). The big change in the DMCA was to make it clear that violating copyrights even when you didn't personally profit from it was still something you could get a big damage on.
Anyway, I've been saying for years that the RIAA's attacks against providers were going to run out and the were going to have to go after individual users. If they have the stomach for it, that'll solve the problem - after a few dozen people declare bankruptcy after receiving multi-million dollar damage awards, people will really begin to understand that when they share music, they're breaking the law, and they're not anonymous.
The real question mark in all of this is what the political ramifications of this will be. Will there be enough public outcry to decriminalize the sharing of music? Personally I doubt it; there is too much money arrayed on the other side, and the long history of copyright in this country is an expansion of copyright. It's hard for me to imagine it going the other way.
One way or another, though, this is finally moving to endgame. I see three possible outcomes:
1) The RIAA fails to have the backbone to prosecute individual end-users. If this happens, the world as we know it today will exist indefinitely - lots of bluster from the RIAA and MPAA while users continue to ignore the law. This is the least likely outcome, in my opinion.
2) The RIAA actually sues people and wins. Enourmous public outcry forces Congress to revisit the issue. Despite heavy lobbying from entertainment (and software!) interests, the portions of the DMCA that made not-for-profit distribution of copyrighted material punishable by large cash fines is rolled back, effectively decriminalizing fil
Theoretically possible. But they'd have to get you to encrypt arbitrary chosen-plaintext, and a lot of it, to check the timings. It's probably easier just to root the box and steal your password with a keyboard sniffer.
As long as we're talking dream keyboards, gimme an OmniKey/101. It's easily programmable to change repeat speeds, to a Dvorak layout, etc., through DIP switches. \ where it belongs, ~ where it belongs, / where it belongs. Solid, perfect key action.
Unfortunately I think they were like $120 new and they aren't made, anymore. Friend of mine found some, reconditioned about five years ago, and I bought 4 - one for work, one for home, one for my wife, and one for spare. Wife now uses a laptop, but the work and home one have never given me a lick of trouble.
And, on the original post, I'll grant him scroll lock. But no bash poweruser could get by without the backtick...
OK, so it's 45 million, not 4.5 million. And I did use a calculator, I just didn't count the digits, properly. You can decide if that's worse than simply guessing wrong. :) Which does give a bit more room, but still, if I were designing it for that, I'd give more wiggle room.
;)
Anyway, I think you already know that I'm not saying the RIAA has our best interest at heart. I just think they're already tracking this stuff, anyway, and I know I wish I'd had GRid back at EMusic, and I wasn't trying to track individual tracks. Even though ours were MP3s and actually would be downloaded and traded, unlike their DRM stuff.
We're reaching the end of any useful information either of us might have on this, I suspect. The size of the ID field doesn't make me suspicious in and of itself. Numbers are cheap, especially numbers the customer doesn't have to punch in. If there has been one lesson we've seen over and over again in the computer industry, it's that arbitrary limits tend to be eventually overflowed, so it makes sense to make ridiculously large systems. It may also be that an unstated design goal is to allow organizations to "waste" big chunks of it - for example, Sony might want the first four digits of its codes to be SONY so it'd be obvious whose albums it is. That seriously degrades the namespace. You could see similar idea for having sub-divisions, record labels, genres, etc. within a company be assigned their own namespaces. This would allow a major label to distribute the allocation of number to their subsidiaries and not need to control it centrally, but doing this to any level would significantly reduce the numbers available to any one subsidiary.
When I said GRid is "useless" for centralized tracking, I may have overstated, a bit. But, my point was, if you want to centrally track downloads based on some key, it would make sense to give each song (not each sale) some unique number. Then you'd just have to look up in a database of 400,000 IDs. If you give each sale a unique ID, and the whole ~900 million-unit US CD market went online, you'd have to look up against an additional 10 billion items per year.
If I were trying to design a system that would both function as a UPC and track individual sales, I'd've put a seperate field for track identifier and sale identifier.
Now, it is true that any label could arbitrarily decide that "the last five digits are a transaction code." But, I think, in this case, the thing borders on not being big enough. If you make it five digits each for the transaction ID and the track ID, that's only 4.5 million, each. There are certainly albums that sell more than 4.5 million copies. But, if you make it six and four, respectively, that makes the transaction ID space big enough, but you can't have more than 1.3 million items in your catelog, which is certainly within an order of magnitude of the biggest catelogs out there. If this system were designed to track albums and transactions in an easily parsable way, I'd expect this field to be more like 16 digits - and why not make it bigger? Numbers, as I've said, are cheap.
Additionally, if a label makes this arbitrary decision, that means that only the label can track the items out there. I'd think it would be desirable to make it easy for third parties to report pirated music, and if you were designing such a system, you'd want to make it what information was the same for every song and what information was different for every sale.
Anyway, bottom line, I agree with you that the record labels want to do this. In fact, I think they already do, for the limited, lame downloadable offerings they have. If that
annoys you, you should be annoyed about that, not about GRid. GRid seems to me to be less than ideally designed to solve the individual sales tracking problem, and definitely does solve the UPC problem. If GRid is for tracking individual sales, it doesn't let them do anything they're not doing, already.
PS: There is one other point that has occured to me - this may be a distraction. They may very quietly announce GRid 2.0 in six months that will be well-designed to track individual sales, and figure no one will notice. That'll be interesting to keep an eye on.
Believe me, I'm not astroturfing. You may disagree with me, but I'm no shill for the record companies. EMusic sided with the RIAA on issues where we thought they were basically correct (i.e., straightforward copyright) and fought them hard when we thought they were wrong (i.e., we filed an amicus brief on Diamond's side in the Rio case). EMusic never joined the RIAA, and the executives while I was there (including myself) were active in causes like the EFF, and opposing the anti-circumvention aspects of the DMCA. I should probably also take this opportunity to reiterate that I no longer work for EMusic. In fact, I'm not involved in the music business in any way at this time, and don't expect to be involved with it directly again in the future. God willing. :)
I'll certainly admit, when I wrote my response, I'd only read the Reuters article. I've now read the
bit of documentation the IFPI has put up, and I remain confident that this is intended to be a UPC-like system, not some centralized tracking of who purchased what. The GRid number looks like: A1-123AB-ABC1234567-X. The A1 is always "A1," it means it's a GRid and not something else. The 123AB is the unique ID for each record company, distributor or retailer. The ABC1234567 is the thing which defines the "release." The X is a checksum (although why such is necessary in an online-only number is unclear to me).
The section which is presumably causing everyone to think this is a tracking system is the long one, the "IP Bundle Number." If this were for tracking, I think there would be one field to identify the transaction, and one to identify the underlying recording. If this is for individual tracking, it is useless for centralized tracking of what songs are being swapped.
I believe that you are interpreting the quotes above in the worst possible context. When Mr. Jessop speaks of "sale, licensing and tracking activities," I believe what he means is, "we license this recording to a distributor and we need to have a centralized way to track how many are sold," not "...a centralized way to track who they were sold to."
They don't need GRid to watermark songs uniquely. As I said, they could just stick a big number in the track. Frankly, the little bit of dabbling in downloadable music the majors have done - all with DRM crap no one wants, which is why no one buys it - generally have already have individual tracking built in, intrinsically. PressPlay, for example, the service from Universal and Sony that people are staying away from in droves, encrypts the music to a key on your system. I don't know for sure, but it's difficult for me to imagine that, given such a file, PressPlay couldn't figure out who it was sold to.
Are they building that info into a watermark, too? Sure, they might be. Who knows? Should we be concerned about that? Absolutely, again with the proviso that no one is buying their downloadable music anyway, since it's such a pain - it's nonportable and you're stuck with their software. But they don't need GRid to track individual purchases - they're doing that, already. They need GRid to easily aggregate purchase tracking. Which isn't very scary to me.
Inserting per-purchase tracking info into songs is something to worry about. But I don't think this is necessary for them to do so. The $250/year is comparable to what UCC charges for UPCs - they've just moved to an annual fee structure, and it runs $150 - $9,000 depending how many numbers you need. In fact, on a per-number basis, the RIAA is probably a lot cheaper.
Also, it's worth noting that I doubt they'll "sell millions of IDs per year." The design of IDs like this aren't that the merchant makes them - merchants will get the numbers from the record companies. The RIAA will tell a record company or destributor, "Your prefix is 12345" and this is a 16-digit number, you can make up everything after 12345." The record company or distributor will tell the merchant, "every time you sell this song, put a tick mark next to 1234567890123456 and tell us once a quarter how many you sold." This makes merchant's lives easier because they have unique identifiers for everything in thier system, and it makes it a lot easier to do stuff like figure out top-40 rankings across multiple distributors since everything has a unique string.
If this seems to contradict anything I said in my previous post, please remember that EMusic is unusual in this model - they are a retailer, but, under the covers, they're a music distributor. They license the music they have from artists, and have the ability to re-license it to others. So, in that sense, they're more like a distribution company, and need their own UPCs (or GRips or whatever). When people like Tower think about doing downloadable music, they'll still need a license (that's the law) but they're not thinking redistribution, so they'll be getting this magic number from the licensor.
Again, bottom line, I think that imbedding a unique tag in songs is something some people would like to do, and it's something to keep our eyes open for. But I don't believe this is to do anything except literally to be an online UPC - to give each unique type of item a globally unique identifier. Certainly anyone selling downloadable music could imbed a unique transaction cookie now. Numbers are cheap, you don't have to pay the RIAA to give them to you. Anyone wanting to track individual downloable sales now could put a unique 128-bit cookie into a song and sleep well knowing there'd never be a collision.
We tried to use actual UPCs, but they are only 12 digits. 6 Are the manufacturer ID, 1 is the classs of the item and 1 is a checksum. That only leaves 4 digits for the SKU - only about 10,000 items. We called UCC (the UPC equivilant of ICANN) and asked for 400,000 numbers, because we figured that would cover something like 90% of the music sold in the US. UCC said, "You realize, if you have a bin of screws, you don't put an individual UPC on every screw, you just assign a number to the bin, right?" We explained that we knew that, and that we really did expect to have 400,000 individual, unique items for sale. They said, "We don't think UPC is the solution for you." So we made up our own SKUs, and gave those to our licensees.
Remember that you need one for the album and one for each song - an an average of 13 per album. Every format you provide that in gives you another set of numbers. So, for example, if EMusic wanted to license its 150,000 song catalog in 128kbps MP3, 256kpbs MP3 and Windows Media, in songs and albums, it'd need nearly 500,000 numbers. And EMusic isn't very big, in music terms. If they need half a million, it's very easy to imagine someone really big might need millions. As all programmers know, you should figure out what the maximum amount you could every possibly need and then increase it by at least an order of magnitude.
'Course, I only paid $10.50, so I guess it's not that big a deal.
No, seriously. Process creation under Linux was time-similar to thread creation on other OSs. That's because Linux was as fast at creating *a process* as other OSs are at creating *a thread*. IIRC, threading was initially implemented in Linux from the process-creation methods, so it was similar in speed (the main advantage in Linux from threads was the shared memory space if your application wanted that sort of thing). That's why Apache 2.0 is bringing NT performance more in line with Linux 1.3 performance: NT's threading speed is a lot closer to Linux's forking speed. Again, I'd like to underscore I'm not an expert on this, and it's possible I'm mistaken about relative benchmarks (is NT w/Apache 2.0 a little faster than Linux w/Apache 1.3? Could be...) but I'm very confident of the basic underlying point, that Linux process creation is essentially comparable to other OSs' thread creation, perhaps even faster.
r uary/000027.html, just one of the first Google links that popped up when I went looking for proof that I'm not on crack: "Linux newcomers often are unaware of the substantial differences between Linux and other operating systems. To implement concurrency, they use multithreading exclusively, mistakenly assuming as high an overhead associated with Linux multiprocessing as on other platforms." In fact, knowing how fast Linux's process creation is relative to other systems' thread creation makes this even more impressive in my mind. This isn't just a bug fix; much like with process creation before it, Linux is doing something fundamentally better than its counterparts.
/. doesn't mean I'm just a Windows-hating troll. I try to make sure all my Windows-hating-troll-posts are at least backed up by facts. ;)
See, for example, http://www.linux.cu/pipermail/linux-prog/2001-Feb
Don't forget: Just because this is
This could be huge for things like webservers, though, which spend a lot of their time kicking off new (logical) processes. As I understand it, on Linux, a big part of the reason Apache 2.0 hasn't taken off (aside from lack of availability of major packages) is that Apache 2.0's main win is in threading support. Under Linux, thread creation hasn't been much faster than process creation, because process creation was so dang fast.
So, am I right in thinking this means threading (and hence Apache 2.0) will be a big win for Linux web servers, now?
Actually, it looks like they fixed the fax law in California, too. The fax law he signed basically undoes the CA fax law (which was awful), which replaces it with the Federal version (which is tougher).
I wish I could find some details on the penalties for the phone spam law, though. I currently get about one phone spam a month (usually at 4am, of course).
Interesting question: If they spam my phone's email address, can I get them for the anti-phone-message violation even though spam isn't prohibited? If so, it might be worth getting a throwaway phone just to go after the spammers...
I think the real value would lie in location-targeted ads. Just getting money from another "click the money" worthless banner pool probably wouldn't even be worth the trouble. But think how much value targeted advertising would be to local businesses - you can give them people who are literally right next door.
Who this kills is the free (as in speech) players - Zinf, XMMS, etc. They can't afford $50k OR $0.75/copy. They can either hope Fraunhofer doesn't notice them, or try to relocate to a place with either no software patents or no Fraunhofer patent, or they can leave MP3. In fact, Linux users in general may be left out in the cold, because I'm not aware of any commercial MP3 decoders for Linux, at all.
Unfortunately, this probably won't be enough to move the world from MP3s. WinAmp will still be downloadable for free, which is all 98% of users care about.
I remember when I was at EMusic, I met with the Thompson guys, who were trying to figure out how to make money on this (circa 1999). I explained to them that nobody was going to pay for a decoder, and that their choice was either to give the decoder away or have people switch to something else. I also suggested the encoder should be free for non-commercial use, in order to cement their current dominance against (then soon-to-be-released) Windows Media.
One of them replied (imagine a German accent), "I see! Vee give avay evrysing for free, and you make more money selling music!"
So, you could say we had a meeting of the minds.
Yes, I did. Sorry, what can I say - I wrote it on STDIN to my codec with limited editing abilities. :)
So, I don't agree, but I think it was a very original and clever thought.
Gur ragrejvavat bs gur benpyr naq vgf pyvrag vf n pynffvp bs nyy svpgvba vaibyivat benpyrf. Frr, sbe rknzcyr, Brqvchf Erk, va juvpu gur benpyr'f cerpvpgvba gung Brqvchf jbhyq zneel uvf zbgure naq xvyy uvf sngure vf jung xvpxf bss gur riragf gung yrnq shsvyyvat gur benpyr'f cerqvpgvba. Frr nyfb gur benpyr va gur Zngevp, jub trg Arb gb oernx fbzrguvat va ure xvgpura ol cerqvpgvat ur'yy oernx vg. Jbhyq fhpu guvatf unccra jvgu n "erny" benpyr? Jub xabjf? Ohg univat gur cerpbtf frg va zbgvba va gur riragf gung yrnq Naqregba gb gur cbvag jurer ur'f ubyqvat n tha ba Pebjr vfa'g n cybg-ubyr; vg'f n shaqnzragny nffhzcgvba bs gur pbafgehpg bs na benpyr nf gurl unir vzcyrzragrq vg. Lrf, lbh pbhyq pbaprvir bs na benpyr gung qvqa'g vavgvngr frys-shysvyyvat cebcurpvrf. Ohg Fcvryoret naq Pb. unfa'g pbzr hc jvgu fbzrguvat cnegvphyneyl rtertvbhf jvgu guvf, naq fbzr zvtug nethr gung va snpg gur ersyrpgvba vg pnhfrf ba guvf frrzvat cnenqbk vf va snpg bar bs gur fgeratguf bs gur cybg, abg n jrnxarff.
Interesting idea - except that, I think, if it were Anderton's made-up world, he'd have Sean back in it.
I thought that quote in the story about the back button was a little bizarre. "I loaded this page, and it popped up these windows. Then I loaded this page again and it popped them up again!"
Well, duh....
I remember I was working at PGP when those cards first really hit. Obviously there were a lot of people there who thought about privacy. :) I remember someone there (heck, might even have been me) had the idea that, much like the "cypherpunks" login with the "cypherpunks" password (which, if you didn't know, is registered in many "registration only" sites, allowing you to login without actually bothering to register), we needed a cypherpunks phone number at Safeway. That way, we could say, "650-555-1212" and get the 5% discount. For those of you who don't know about Safeway, you can enter your phone number as a "key" to get the discount. You can also tell the clerk your phone number, if you're too stupid to type it on the pad, and I've always enjoyed being there at 2AM and seeing the tall, leggy blonde announce her phone number for all to hear.
I then started thinking about the reports that computer was going spit out, because the vast majority of people who would do that are male programmer types (with a handful of women). "Bob! Look at this guy! Last week he purchased 372 liters of Mountain Dew, 27 frozen pizzas, 39 copies of Playboy and one box of Maxi Pads!"
During this time I militantly refused to get such a card and give up my privacy for something as minor as a 5% discount. However, my wife went ahead and applied, but somehow managed to get our phone number wrong. I remember at one point I was buying some beer that was like $2 off per six pack, or something ridiculous. At that time, they were really pushing the cards, and, unless you were willing to be very rude, you got in this catch-22, where, if you told the clerks you didn't have a card, they'd hassle you about how stupid you were being for not saving $6 on the 3 six packs you were buying, or, if you said you left your card at home, they'd hassle you about giving them your phone number.
Anyway, this clerk asked me if I had a card. "Yes, but it's not with me." She wanted to know the number. I gave her my number (obfuscated for this story as 650-555-3940). She punched it in, no such account. She said, "Let me try another one, maybe someone typod it." She typed a number, and the discount popped up. "Good call," said. "What was the number?" "650-555-3949," she said. "Are you Mr. Ngzrschy?" "Nope!" I said. "Thanks!"
Ever since then I've used that number. The name is very difficult to pronounce, and the clerks usually try it one way, then another, then ask, "Did I get that name right?" I always say, "Absolutely!"
Quite specifically (I've been there and done that) what you must do is certify under penalty of perjury that either the supposed copyright owner is mistaken, and you do have the right to distribute the content, or that the owner is mistaken and you never did distribute the content. Once you do that, your ISP is indemnified and may (but doesn't have to) put your site back up. At that point, the copyright-holder can sue you, at which point I believe the ISP has to take you back down until the suit is resolved (although I'm not 100% sure on that as I've never taken a case that far, personally).
But, yes, you're right, for many providers, once you get involved in the process at all, you're not worth the time and money.
And I agree that it is one of the more sensical parts of the DMCA - it gives the ISP a positive defense and sets out pretty clearly the legal path everyone can use to avoid prosecution.
Also, there is no getting around the legal problem. The DMCA is written such that anyone that provides bits to you is an ISP, and they can be provided notice of your copyright violations. Once they receive that notice, they must either remove the content (i.e., by getting you to do it via threats, or by cutting off your service), or they are held legally responsible. Since you probably pay them thousands of dollars a year at most, and willfull copyright violation is $25,000 per occurance, your ISP will not back you, and will pull the plug, because it's not worth the risk.
/. would disagree with (preventing spamming, for example), but many of them there might be some controversy (prohibiting un-PC speech). Again, you're not going to be able to avoid these unless you become a backbone provider. Which is probably a bit over your budget ;).
Theoretically, I suppose, you could be a backbone provider and not have anyone upstream. But unless you're planning on buying Sprint or something, you will have to deal with the fact that there is someone upstream who can pull the plug on you solely because your content has been complained about by a copyright owner.
Also, realistically, every provider has some terms of service. Some of them no one on