Since this is such OLD news, I figured I'd post something that was at least new to most people (even if it is old in itself).
Back in September, my wife and I attended a book signing for Orson Scott Card in Virginia, and I took copious notes on my Pilot, but never posted them. He spent about an hour talking about the movie, his books, etc.
Rather than trying to re-write my notes, I'm just going to paste them in here and do some quick abbrev expansions, etc.. Hopefully, they'll still make sense.:-)
Ender's Game Movie
"jake lloyd 'is' ender, in every way that matters to me" -- Said that Lloyd really enjoyed the book, and could do a great job with the part, and that we shouldn't judge his acting skills based on SW:TPM
Movie should have some cool stuff, surprises
OSC wanted to do new version of Enders Game with new stuff (like a movie novellization) - tom doherty (publisher? editor?) said no
Hasn't watched 6th Sense, and won't, because he feels that his story Lost Boys will never filmed because it's too similar to 6th sense (which I disagreed with, later, and he said that the "catch" ("he's dead!") was too similar to Lost Boys' catch. I still think Hollywood wouldn't care.)
He also said that the 6th sense boy (don't remember the actor's name) is to old to play Ender convincingly
Keep in mind that there are too many variables, jake lloyd still completely uncertain - he could be 15 by the time the movie gets off the ground
His ultimate dream - film both Ender's Game and Ender's Shadow at once, same cast, etc.
Working on integrating the flash suit gun into glove (he described this, and I remember it sounding cool)
Some other stuff
Working on a tv pilot called bordertown, filmed in mexico
Another book after Ender's Shadow, Shadow of the Hegemon, about Bean as the right-hand-man, general, shadow, of Peter the Hegemon (was going to do a book about Peter, but publisher didn't like it, and later, neither did OSC -- too dark a character, not enough room for development, etc.)
Following that, would like to do a book about Petra
Expect two more books in the Alvin Maker series: Crystal City and Master Alvin
"And if you don't know that Alvin is really Joseph Smith and Arthur Steward is really Brigham Young and that they're going to...(forget the whole quote), then You Haven't Been Paying Attention!" (I never noticed the parallels between the two, personally...:-) )
Will be doing Pastwatch books on Adam & Eve, and the Flood (don't remember if that was Noah's flood, or Atlantis. There's a Pastwatch Atlantis short story on OSC's web site, http://www.hatrack.com/osc/storie s/atlantis.shtml.
Expect three books about biblical women: sarah, rebecca, and rachel, presumably in same vein as Stone Tables or Saints
Working on a 6-part ANIMATED TV series based on Treason (!)
Let on that the Homecoming series is detailed retelling of Book of Mormon (never noticed this, either, and there's a great essay about the shit he took from other Mormons about his "plagiarizing" of this on his web site: http://www.hatrack.com/osc/art icles/openletter.shtml.
That's about all I have...if you ever get a chance to see him, I recommend it highly -- he was a funny, intelligent, engaging speaker and answered all questions fully (and sometimes got on a soapbox, but he put pretty clear disclaimers around those self-described diatribes...)
This is actually pretty easy to do. We have three sites (all internal) that all run with a MySQL DB storing all web content, and uses PHP/Apache as the Browser/DB interface. By using an apache "Alias Match" directive, we re-write everything to point to a primary PHP script:
AliasMatch ^/(.*)/home/web/index.html/$1
This front-end does a lot of (admitedly, crude) parsing of the rest of the URI line to determine what "document" in the DB to look up, and which subordinate page, or if it's supposed to be instead generating an image, or whatever. The main script also looks up styles for each document, builds navigation bars, etc.
Works pretty well. Not nearly as flexible as if I'd actually thought it through before writing it, but it fits our needs admirably.
Why'd we go to such a complicated approach? Because we have bunches of InfoSec engineers, who really don't want to worry about HTML, writing web pages and reports. We've got a GUI front-end with a nice wysiwyg HTML editor that hits the documents in the DB directly, and all changes happen on the "live" HTTP server immediately. It's completely scannable because we use a web-get sort of tool to create a static "snapshot" of the final report before we send it to customers.
I've thought for a while that what we really need is a system we can use over the phone, on paper applications, etc. What I'd like to see is some sort of centrally managed PKI (gov't, likely), that gives everyone a little credit-card calculator (like the SecurID tokens). Then, when they're giving an order, or signing a document, they give the number on the token (SSN or something), the date as displayed by the token, and the cryptographic hash of the two (as calculated by the token). Alternatively, the information requestor could provide additional numbers to enter into the hash (like an order number or something).
The recipient of the information would take all the data, do some crypto-magic on it, and validate it against the public key for the individual as defined in the big-brother database. If the signing date is too old (like they gave a date from two weeks ago), reject the signature.
If the DB says that the token was reported stolen on some date, and the signing date was after that date, reject the signature (if it was signed before, accept it, within normal parameters--like if you're checking a signature on record rather than processing a new order).
This provides a very secure, use-once, electronically verifiable signature in any medium -- web, telephone, vending machine, mail-in credit card application, whatever.
What's wrong with this idea? (aside from the obvious issues of actually making it happen)? I probably forgot to mention one or two things, as I've never bothered to write this down before (I've thought about it off and on for the last few years), but if anyone can tell me why this can't work, I'd love to hear it...
I was trying to do that here for our training department, and had terrible experiences.
I could get NT, or Linux, or whatever, loaded onto a bootable Jaz disk, and it'd run really great, just like a hard disk. But the minute I tried to do any kind of mass duplication of the data (using DD, mostly), I'd start having problems.
Specifically, I'd get media errors up the wazoo--SCSI problems, disk problems, etc. We replaced at least three drives, but even then at least 30% (closer to 50%) of our 2G Jaz disks simply didn't work. We eventually trashed the whole setup and now use removable IDE drives and multicast Ghost images.
I asked for help multiple times on USENET, but all I ever got back was "Jaz drives suck. Try something else." Same response from just about every other person I spoke with. Don't get me wrong, I love Jaz for file storage and archiving, but for dumping an OS onto it repeatedly and using it as boot device--I dis-recommend it completely.
SF Novels just don't adapt well to films..... If you want to make a good SF film, the trick seems to be to use a short story.
Don't forget that Ender's Game was orginally a short story (or novella or novellette or something). Mostly from the Battle Rooms through to the final battle. I seem to recall it opens with "Remember: The enemy's gate is DOWN." What a great opening line!
I haven't read the latest script yet, but it's entirely possible that OSC will concentrate more on the short-version of the novel than the full-out novel as most of us know it. (for the original version, check out the hardcover edition of Maps In A Mirror).
Also, note that I don't think OSC has specifically said he wants Jake Lloyd over all others, I think he's said more that he was suitably convinced by Lloyd that a child really could pull off the real Ender role that he is re-doing the film to change the focus...And I'm quite happy about that (since the original script excerpt gave away some surprises up front...)
Here's a quick-n-dirty (quite dirty, I admit) way to help show kansas how stupid this is:
Effective Immediately, all higher-educational institutions in the US automatically REJECT all applicants from Kansas State Public Schools, on the grounds that they obviously don't know basic science.
See how long Kansas keeps their stupid rules in effect that way!
several people have correctly pointed out that "m" and "M" already have different meanings in SI units...silly me, I totally forgot that (if I still did any EE stuff I probably wouldn't have:-) )
So, maybe Knuth does have the answer (no real surprise there). Use "K" for 1000, "KK" for 1024. And so forth.
Dunno. S'long as I don't get confused when reading stuff on the screen, I'd be happy.
Thirdly, I believe that there is a difference in captialization for 'kilobyte' depending on which kind you mean. 1 kB = 1000 bytes, but 1 KB = 1024 bytes.
I hadn't thought of that before. This de-escalates the matter to some extend. But... how do you pronounce the difference?
I talk about why this really makes a difference elsewhere here (Forget binary, stick with base-10 for byte counts!), and came up with the same idea (lowercase k for "true" kilo, uppercase for "binary" or "large" kilo). How do you pronounce the difference? Dunno. Maybe just "kilo" vs "K" or "megabytes" vs "MB".
Personally, I'm more concerned with visual display--that's where it's been an issue with me.:-)
> If we change the meaning of kB on a disk, > then why not do the same for memory?
why not? what does it harm? All we're changing is how things are displayed to the user, to make it actually *make sense*. However, I do agree that memory chip boundaries actually are on binary breaks, so it might make more sense there.
Of course, by my suggestion, you *can* do both. Memory is "32MB" while a Zip disk could be 100 mB, to distinguish a "true" binary-based "mega" from a decimal-based one. The key here is to use whatever system makes the most sense. In specifying memory size, maybe binary makes sense. In displaying a file size while showing only the most significant digits, decimal makes more sense.
> Things in computers are measured in powers > of 2 not powers of 10. Get over it.
Are they? Where do you actually "measure" anything on a computer, other than in an end-user display? If I declare an array to have 1k of elements, I don't say "int foo(1k)" I say "int foo(1024)" (or something, been a while for me.:-) )
The problem isn't the words, it's how the numbers change drastically when you apply the suffix.
Yesterday I was copying images from a Linux box to NT for a CD, and was concerned that the files hadn't copied. "ls" showed something like "613,123,456" bytes, while the detail list in Explorer said "598 MB" and the status-bar said "584,720 KB". So, if I look at the most significant digits (the first check to see if the file's copied), I see either 613, 598, or 584, depending on where I look. Now tell me that any "normal" user is going to understand that distinction!
In a base-10 system, however, 613,123,456 B ~= 613,124 kB ~= 613 mB, so the numbers at least *look* similar.
Is there any reason we really need to do things in binary for this? I mean, you and I don't really give a damn that a disk contains exactly N multiples of a 10-bit word of bytes, we care how many bytes total are on it. And, in a decimal society, we use powers of 10 to see that.
Maybe we could stick with capital K for base-10, and lowercase k for base-2 (or reverse, I don't remember the "official" case for base-10 units). Kind of like how 'b' means bits or bytes, depending. Let's just make it clear, eh?
The monitor manufacturers are finally getting with the program for visible area measurements, maybe the same thing could happen here ("A 2.5gB drive (2.5 billion bytes)" or "2.6 GB (2.684 billion bytes)").
Isn't this the way that the old Archie system worked? Lots of different servers would index stuff, and every night they'd exchange what they'd learned (to spread the knowledge, and to ensure that none of the other servers revisited sites too soon). They claimed (IIRC) to visit every public FTP server at least once a month.
The nice thing about this approach would be that you could have multiple front-ends, too, so the search engine "site" itself wouldn't get bogged down--automatic mirrors!
This should be fairly simple to implement--a list of sites vistied (with dates) on the one hand, and index diffs (for the content itself). The only question is: How do we keep it from getting "sold out" and losing quality? (not that selling out is bad, but someone mentioned lycos going to hell after getting sold).
> The original question asked about a mkdvdfs, > which implies they want something like being > able to simply put an MPEG-1 or MPEG-2 encoded > video stream onto the disc and expect it to be > played with standard DVD software as a DVD
Yes, that's what I was asking...doesn't have to be in "streaming" mode, though (in case that's what you're assuming). I would be perfectly happy requiring 4+G of scratch space for the creation of the image, on magnetic media, before getting burned to the DVD.
But, yeah, a program that could take a menu file (say, an HTML file), a list of different video files (mpeg, quicktime, whatever), and build a complete image that a DVD-writer could write to a consumer DVD player-readable disc.
I understand the problem with decoders for reading commercial DVDs, but IIRC, it is also possible to write non-encrypted DVDs. How far off is the Linux community from a mkdvdfs program, so I can shove all those cool Star Wars trailers onto a DVD I can watch at home?
After that, the next big step would be video-capture cards....then a hook-up to TiVO...
> I would never get rid of my SLR unless they > make a digital camera that you could...
> a) change the lenses
There's a manufacturer working on a "digital camera" drop-in film canister for standard 35mm cameras. Check out: www.imagek.com (actually, it seems to be down this moment). Last I heard, they were hoping for 1280x1024 resolution (or something close).
I hope they haven't folded--that was (and still is) the best hope for digital cameras, I think--retrofitting all our existing cameras. Best of both worlds.
> Alot of people don't realize the power that these companies wield (ASCAP, BMI, SESAC). > They have the legal right to enter any store, club, resteraunt, or place of business and > demand to see proof of current licensing
What gives them that right? What law provides them that power? If there's no law authorizing such a right, then why are they allowed to do it?
As far as I can tell, this is a civil matter, there're no laws actually involved. Or does US copyright law specifically appoint ASCAP/BMI/whoever as copyright police?
Drink name: Jumpstart Recipe: Equal parts grain alcohol, Jolt Cola Purpose: For people who want to make really stupid decisions at double normal speed.
Okay, everyone's talking about putting a mess of keywords in their.sig to overload Echelon systems. I suggest that such efforts are worthless:
Flag Message If (~ [keywords]) Unless (~ ([keyword]\s*[keyword]){3+})
(or something like that). The point is, it should be fairly easy to auto check a message to see if it contains a string of keywords in a row.
Better to randomly distribute keywords throughout your text, methinks.
Also, correct me if I'm wrong, but this whole discussion centers around traffic going out of the country, right? There's (to my knowledge) no real way for the NSA to monitor every single internet pipe in the country (and the backbones are far too busy to sniff--can we really build a terabit sniffer?)
I hate to be picky, but these machines scan the details of your iris (the color in your eyes around the pupil), not the retina (which requires, IIRC, bright light and a close-in lens).
Other-n-that, pretty darned cool. Though I'd still like to have a code of some sort (might be nice to have an "emergency" code that'd provide money, but call the cops, too...or something like that...)
A place we might be able to find a ready-made database of albums and tracks in the WWW music database at www.roadkill.com. Lotsa albums, track info, etc. Or, if anyone has older copies of the DB. Or, if somebody (like, say, end users) downloads the full DB somehow (if they haven't been presented with the terms, and are acting under the terms that came with their app, who's to stop 'em?)
Slashdot Mirror
Back in September, my wife and I attended a book signing for Orson Scott Card in Virginia, and I took copious notes on my Pilot, but never posted them. He spent about an hour talking about the movie, his books, etc.
Rather than trying to re-write my notes, I'm just going to paste them in here and do some quick abbrev expansions, etc.. Hopefully, they'll still make sense. :-)
Ender's Game Movie
Some other stuff
That's about all I have...if you ever get a chance to see him, I recommend it highly -- he was a funny, intelligent, engaging speaker and answered all questions fully (and sometimes got on a soapbox, but he put pretty clear disclaimers around those self-described diatribes...)
-david.
This front-end does a lot of (admitedly, crude) parsing of the rest of the URI line to determine what "document" in the DB to look up, and which subordinate page, or if it's supposed to be instead generating an image, or whatever. The main script also looks up styles for each document, builds navigation bars, etc.
Works pretty well. Not nearly as flexible as if I'd actually thought it through before writing it, but it fits our needs admirably.
Why'd we go to such a complicated approach? Because we have bunches of InfoSec engineers, who really don't want to worry about HTML, writing web pages and reports. We've got a GUI front-end with a nice wysiwyg HTML editor that hits the documents in the DB directly, and all changes happen on the "live" HTTP server immediately. It's completely scannable because we use a web-get sort of tool to create a static "snapshot" of the final report before we send it to customers.
At any rate, I think it's cool... :-)
david.
I've thought for a while that what we really need is a system we can use over the phone, on paper applications, etc. What I'd like to see is some sort of centrally managed PKI (gov't, likely), that gives everyone a little credit-card calculator (like the SecurID tokens). Then, when they're giving an order, or signing a document, they give the number on the token (SSN or something), the date as displayed by the token, and the cryptographic hash of the two (as calculated by the token). Alternatively, the information requestor could provide additional numbers to enter into the hash (like an order number or something).
The recipient of the information would take all the data, do some crypto-magic on it, and validate it against the public key for the individual as defined in the big-brother database. If the signing date is too old (like they gave a date from two weeks ago), reject the signature.
If the DB says that the token was reported stolen on some date, and the signing date was after that date, reject the signature (if it was signed before, accept it, within normal parameters--like if you're checking a signature on record rather than processing a new order).
This provides a very secure, use-once, electronically verifiable signature in any medium -- web, telephone, vending machine, mail-in credit card application, whatever.
What's wrong with this idea? (aside from the obvious issues of actually making it happen)? I probably forgot to mention one or two things, as I've never bothered to write this down before (I've thought about it off and on for the last few years), but if anyone can tell me why this can't work, I'd love to hear it...
-----
david.
Ugh!
I was trying to do that here for our training department, and had terrible experiences.
I could get NT, or Linux, or whatever, loaded onto a bootable Jaz disk, and it'd run really great, just like a hard disk. But the minute I tried to do any kind of mass duplication of the data (using DD, mostly), I'd start having problems.
Specifically, I'd get media errors up the wazoo--SCSI problems, disk problems, etc. We replaced at least three drives, but even then at least 30% (closer to 50%) of our 2G Jaz disks simply didn't work. We eventually trashed the whole setup and now use removable IDE drives and multicast Ghost images.
I asked for help multiple times on USENET, but all I ever got back was "Jaz drives suck. Try something else." Same response from just about every other person I spoke with. Don't get me wrong, I love Jaz for file storage and archiving, but for dumping an OS onto it repeatedly and using it as boot device--I dis-recommend it completely.
Just my thoughts....
david.
Don't forget that Ender's Game was orginally a short story (or novella or novellette or something). Mostly from the Battle Rooms through to the final battle. I seem to recall it opens with "Remember: The enemy's gate is DOWN." What a great opening line!
I haven't read the latest script yet, but it's entirely possible that OSC will concentrate more on the short-version of the novel than the full-out novel as most of us know it. (for the original version, check out the hardcover edition of Maps In A Mirror).
Also, note that I don't think OSC has specifically said he wants Jake Lloyd over all others, I think he's said more that he was suitably convinced by Lloyd that a child really could pull off the real Ender role that he is re-doing the film to change the focus...And I'm quite happy about that (since the original script excerpt gave away some surprises up front...)
See how long Kansas keeps their stupid rules in effect that way!
david.
several people have correctly pointed out that "m" and "M" already have different meanings in SI units...silly me, I totally forgot that (if I still did any EE stuff I probably wouldn't have :-) )
So, maybe Knuth does have the answer (no real surprise there). Use "K" for 1000, "KK" for 1024. And so forth.
Dunno. S'long as I don't get confused when reading stuff on the screen, I'd be happy.
Thirdly, I believe that there is a difference in captialization for 'kilobyte' depending on which kind you mean. 1 kB = 1000 bytes, but 1 KB = 1024 bytes.
:-)
I hadn't thought of that before. This de-escalates the matter to some extend. But... how do you pronounce the difference?
I talk about why this really makes a difference elsewhere here (Forget binary, stick with base-10 for byte counts!), and came up with the same idea (lowercase k for "true" kilo, uppercase for "binary" or "large" kilo). How do you pronounce the difference? Dunno. Maybe just "kilo" vs "K" or "megabytes" vs "MB".
Personally, I'm more concerned with visual display--that's where it's been an issue with me.
> If we change the meaning of kB on a disk,
:-) )
> then why not do the same for memory?
why not? what does it harm? All we're changing is how things are displayed to the user, to make it actually *make sense*. However, I do agree that memory chip boundaries actually are on binary breaks, so it might make more sense there.
Of course, by my suggestion, you *can* do both. Memory is "32MB" while a Zip disk could be 100 mB, to distinguish a "true" binary-based "mega" from a decimal-based one. The key here is to use whatever system makes the most sense. In specifying memory size, maybe binary makes sense. In displaying a file size while showing only the most significant digits, decimal makes more sense.
> Things in computers are measured in powers
> of 2 not powers of 10. Get over it.
Are they? Where do you actually "measure" anything on a computer, other than in an end-user display? If I declare an array to have 1k of elements, I don't say "int foo(1k)" I say "int foo(1024)" (or something, been a while for me.
The problem isn't the words, it's how the numbers change drastically when you apply the suffix.
Yesterday I was copying images from a Linux box to NT for a CD, and was concerned that the files hadn't copied. "ls" showed something like "613,123,456" bytes, while the detail list in Explorer said "598 MB" and the status-bar said "584,720 KB". So, if I look at the most significant digits (the first check to see if the file's copied), I see either 613, 598, or 584, depending on where I look. Now tell me that any "normal" user is going to understand that distinction!
In a base-10 system, however, 613,123,456 B ~= 613,124 kB ~= 613 mB, so the numbers at least *look* similar.
Is there any reason we really need to do things in binary for this? I mean, you and I don't really give a damn that a disk contains exactly N multiples of a 10-bit word of bytes, we care how many bytes total are on it. And, in a decimal society, we use powers of 10 to see that.
Maybe we could stick with capital K for base-10, and lowercase k for base-2 (or reverse, I don't remember the "official" case for base-10 units). Kind of like how 'b' means bits or bytes, depending. Let's just make it clear, eh?
The monitor manufacturers are finally getting with the program for visible area measurements, maybe the same thing could happen here ("A 2.5gB drive (2.5 billion bytes)" or "2.6 GB (2.684 billion bytes)").
Isn't this the way that the old Archie system worked? Lots of different servers would index stuff, and every night they'd exchange what they'd learned (to spread the knowledge, and to ensure that none of the other servers revisited sites too soon). They claimed (IIRC) to visit every public FTP server at least once a month.
The nice thing about this approach would be that you could have multiple front-ends, too, so the search engine "site" itself wouldn't get bogged down--automatic mirrors!
This should be fairly simple to implement--a list of sites vistied (with dates) on the one hand, and index diffs (for the content itself). The only question is: How do we keep it from getting "sold out" and losing quality? (not that selling out is bad, but someone mentioned lycos going to hell after getting sold).
> The original question asked about a mkdvdfs,
> which implies they want something like being
> able to simply put an MPEG-1 or MPEG-2 encoded
> video stream onto the disc and expect it to be
> played with standard DVD software as a DVD
Yes, that's what I was asking...doesn't have to be in "streaming" mode, though (in case that's what you're assuming). I would be perfectly happy requiring 4+G of scratch space for the creation of the image, on magnetic media, before getting burned to the DVD.
But, yeah, a program that could take a menu file (say, an HTML file), a list of different video files (mpeg, quicktime, whatever), and build a complete image that a DVD-writer could write to a consumer DVD player-readable disc.
Would be cool, no?
I understand the problem with decoders for reading commercial DVDs, but IIRC, it is also possible to write non-encrypted DVDs. How far off is the Linux community from a mkdvdfs program, so I can shove all those cool Star Wars trailers onto a DVD I can watch at home?
After that, the next big step would be video-capture cards....then a hook-up to TiVO...
> I would never get rid of my SLR unless they
> make a digital camera that you could...
> a) change the lenses
There's a manufacturer working on a "digital camera" drop-in film canister for standard 35mm cameras. Check out: www.imagek.com (actually, it seems to be down this moment). Last I heard, they were hoping for 1280x1024 resolution (or something close).
I hope they haven't folded--that was (and still is) the best hope for digital cameras, I think--retrofitting all our existing cameras. Best of both worlds.
david.
> Alot of people don't realize the power that these companies wield (ASCAP, BMI, SESAC).
> They have the legal right to enter any store, club, resteraunt, or place of business and
> demand to see proof of current licensing
What gives them that right? What law provides them that power? If there's no law authorizing such a right, then why are they allowed to do it?
As far as I can tell, this is a civil matter, there're no laws actually involved. Or does US copyright law specifically appoint ASCAP/BMI/whoever as copyright police?
Drink name: Jumpstart
Recipe: Equal parts grain alcohol, Jolt Cola
Purpose: For people who want to make really stupid decisions at double normal speed.
Okay, everyone's talking about putting a mess of keywords in their .sig to overload Echelon systems. I suggest that such efforts are worthless:
Flag Message If
(~ [keywords])
Unless
(~ ([keyword]\s*[keyword]){3+})
(or something like that). The point is, it should be fairly easy to auto check a message to see if it contains a string of keywords in a row.
Better to randomly distribute keywords throughout your text, methinks.
Also, correct me if I'm wrong, but this whole discussion centers around traffic going out of the country, right? There's (to my knowledge) no real way for the NSA to monitor every single internet pipe in the country (and the backbones are far too busy to sniff--can we really build a terabit sniffer?)
david.
I hate to be picky, but these machines scan the details of your iris (the color in your eyes around the pupil), not the retina (which requires, IIRC, bright light and a close-in lens).
Other-n-that, pretty darned cool. Though I'd still like to have a code of some sort (might be nice to have an "emergency" code that'd provide money, but call the cops, too...or something like that...)
A place we might be able to find a ready-made database of albums and tracks in the WWW music database at www.roadkill.com. Lotsa albums, track info, etc. Or, if anyone has older copies of the DB. Or, if somebody (like, say, end users) downloads the full DB somehow (if they haven't been presented with the terms, and are acting under the terms that came with their app, who's to stop 'em?)