I've been making VCDs of my nephew. He lives in Texas and I live in California, so it's about the only involvement in his life that I have. I make these VCDs using only open-source tools (some of which I made for this purpose and haven't released quite yet).
I use VCDs because they're easy to make with a commodity burner, play on most DVD players, and are suitably versatile, compatible, and easy to use.
Now, it sounds like the following scenario is on the horizon:
This bill gets passed and signed into law.
The MPAA refuses to give CSS keys to DVD player manufacturers unless they agree to only play watermarked discs. (Witness region coding.)
The manufacturers agree, since otherwise they can't play most DVDs (DeCSS etc being illegal).
I can't afford to be a registered publisher and get the MPAA's watermarking tools, so I can't watermark my discs.
I can't find any tools to create a watermark (copyright circumvention technology), so I have to reverse-engineer it myself and write my own.
I can create my VCDs with a faked watermark, but it's illegal for me to send them to my sister or parents (trafficking).
My nephew, lacking the support and nurturing from his uncle, grows up to lead a life of crime, possibly in the senate.
Is this about right?
That's okay... I'm musically inclined and can still write songs I can send to him... except... gee, I just got a sense of deja vu.
Just a note to wish you all a happy sysadmin appreciation day!
I know that I, like so many, make lots of random demands on your time
and patience, and so frequently don't think about what you go through
to keep our systems-- servers, workstations, labs, infrastructure,
everything-- running smoothly.
In the past, I used Emacs's VC features extensively. (This is the front-end over version control systems.) Now, I use both PCVS (added in Emacs 21, takes advantage of CVS's features) and VC extensively.
It's great. I wanna work on a file? I open it, press C-x C-q to get the latest version. I edit it, then press C-x C-q again to check it in. If there was a conflict, I get an easy to use conflict resolution browser. I fix it, and commit again. I type in a log message (viewing the diffs to help me by pressing C-x v =), press C-c C-c, and I'm done. All that is under VC. It's easy as falling off a log.
PCVS adds the ability for me to quickly look over directories to see what the status of different files is. From there, I can mark files and perform batch updates.
Post-failure analysis is easy too. Annotate, diff, log, etc. are all available at the touch of a button while I'm editing the file in question. Nothing to it.
I see a lot of people who don't realize how easy these can make CVS to use. I use CVS all the time, and have no complaints.
First off: never underestimate the value of putting research notes in your comments! A simple "This averages O(NlogN), but is worse if the data is presorted" can really make somebody's day.
Now, the long rambling description of how I like to see comments:
Every file should have, right after the boilerplate (after copyright, before #includes etc) a brief description of that file.
;;; This implements the SAMHAIN algorithm for performing ;;; constraint propogation. The caller passes a list of nodes... ;;; [Description of what SAMHAIN does ommitted for brevity on/.] ;;; ;;; The algorithm here is loosely based on the one in "Paradigms of ;;; Artificial Intelligence Programming", chapter 17. There, it was ;;; used as part of a vision algorithm, but it's still labelling a ;;; graph by constraint propogation.
Name your functions something concise, and accurate, but not necessarily precise. You don't need sort-sequence-on-predicate when sort will do just as nicely.
The same goes for variables. Using i and j for numeric iterators is fine, but you rarely should use foo and bar. Most variables should also have a short (usually <20 char) comment, although globals should have a longer comment, possibly describing how they're used.
Every function should have a docstring. In some languages, such as C, this is normally comments at the beginning of the function. In some, such as Lisp, there are conventions for including the docstring in a manner that the compiler will recognize.
The first line of the docstring should be a self-contained sentence that tells what the function does. The rest can go into detail about how to call it. The purpose of this bit is "what does a caller of this function need to know". Wait on the implementation notes for now... we want the caller information to be all one, tidy package.
(defun sort (predicate sequence) "Destructively sort SEQUENCE. Predicate should be a function of two arguments, and should return T if its first argument should precede the second."
If your language does have docstring support (either directly or through an external tool), then implementation notes belong in comments, not the docstring. Either way, put them after the caller information, so that somebody who just wants to use your function doesn't need to read them.
(defun sort (predicate sequence) "Destructively sort SEQUENCE. Predicate should be a function of two arguments, and should return T if its first argument should precede the second." ;; We use a modified partition-exchange sort. ;; See also Hoare, C.A.R., "Quicksort", The Computer Journal, 5:1, pp. 10-15, 1962.
As an extention of this idea, functions should begin with a brief overview of how they work. (For extremely simple functions, this may be omitted.) If the function implements a formal algorithm, such as a sort or hash algorithm, then a formal description is certainly not out of place, or give a reference. This is also a good place to note any behavorial characteristics.
;; See also Hoare, C.A.R., "Quicksort", The Computer Journal, 5:1, pp. 10-15, 1962, ;; and Knuth, D.E., "Sorting and Searching", The Art of Computer Programming, ;; Vol. 3, pp. 114-123, 145-149, 1968, particularly algorithm Q. ;; ;; Takes O N lg N average time. This implementation uses median ;; selection to avoid its O N**2 worst-case behavior. ;; ;; If the data has a pre-existing order, use mergesort instead.
Divide your code into "paragraphs", between 5 and 20 lines long. Skip a blank line between paragraphs. This also helps find areas that are good candidates for factoring out into separate functions.
Each paragraph may start with a block comment describing either what that paragraph does, or at least the program's state at that point in execution. Feel free to make these as descriptive as you like; they're the landmarks for somebody reading the code.
;; If the inner loop only executed once, then there were only enough ;; elements for two subsequences given n, so all the elements have ;; been merged into one list. Start-1 will have remained 0 upon exit.
Loop guards frequently should have a one-line comment describing what they're testing for, in terms of the algorithm as a whole.
(when (<,end-1,vector-len) ; there are enough elements for a second run
If a line's meaning isn't immediately clear, then clarify it with a one-liner.
(let* ((retval-cons (cons:placeholder list));:placeholder will be deleted later
Any one-liners may be expanded to multi-liners if you need to:
/* log_forward ignores SIGCHLD, so we must reset it to catch the * sendmail exit status. */ signal (SIGCHLD, SIG_DFL);
Mark areas that need investigation or more work with a comment of "FIXME"; that makes grepping later on much easier.
res = pthread_mutex_unlock(&msg_thread->mutex); / * FIXME The error handling here needs to be more robust. */ if (res != 0) d_errc(EX_OSERR, res, "cannot release worker thread");
You can also use XXX for a similar purpose, or (what I do) to mark areas of grave significance.
/* Frees all transitions out of a state. XXX Whatever calls this must * either reinitialize the transitions slist or free the structure. */ static void free_transitions(struct matcher_u *matcher)
Don't worry about descriptive comments being too verbose. Descriptions of program state, why something exists, research notes, or prose all have their place in comments. The only time I've read a file and thought "Gee, this is overcommented" was when it had template comments with changelogs and argument lists.
Now what do you not use comments for?
Don't keep a changelog in your code. Your source-control system does a much better job.
Don't repeat the argument list. The argument list itself does a perfectly fine job of that, and will always be up-to-date. If the purpose of each argument isn't clear by its name, then add a one-line comment to the arguments. (Note: In Perl, don't shift the arguments off as needed. Get all the arguments off in the first line of code if possible, such as my ($self,$filename,$options) = @_; in order to let somebody calling the function to have an argument list available!)
Don't document the language (eg, explaining ++). This not only is unhelpful, but distracts from useful comments. If somebody doesn't know what ++ does, they can look it up.
Credits: Examples snipped and adapted from my own development, as well as CMUCL and FreeBSD sources.
I can't find my favorite (it's in a collection of computer horror stories I misplaced), but here's a few from old Symbolics lore. The first is available in a few places on the net, the second is probably only on SMBX.
T306 Tales
The first machine we had in the STX (Houston regional) office was an LM-2 with a T306 disk drive (you know, one of those big removables that ran on 220 volts). Before that, we had only a couple of TI silent 700s to read our mail with (over 300 baud lines).
Well, when the delivery truck brought the machine, a couple of people in the office happened to be idly watching out the window. Although the truck had a lift gate, somehow the delivery guys managed to drop the T306 about 4 feet onto the pavement! They tried to give it to us anyway without mentioning the incident, but we told them we'd seen what happened, and that their insurance would have to cover the damage
William D. Gooch
3600s Come to Austin
The University of Texas at Austin was one of the early 3600 customers. When their first two 3600s arrived, one of them had clearly been damaged in shipping. The top side panels on both sides were bent inward, and the Fujitsu Eagle disk drive had broken completely free from its mounts and was just sitting in the bottom of the machine. However, once the disk mounts were replaced, the machine fired up and worked fine, with the exception of a funny noise from the fan which could never quite be eliminated.
The first 3600 arrived at the Austin SMBX office in a moving van without a liftgate. While the delivery men were getting it off the truck via a long ramp out the side door onto the front patio of our office building, somehow the machine got away from them and was rolling free down the ramp! This was quite a sight - a big new several hundred pound machine rolling down this narrow ramp, with burly guys alongside trying to get a grip on it and stop it. They didn't get it stopped until it was off the ramp, but somehow it didn't fall over. Worked fine.
William D. Gooch
War Stories
Bill Gooch's story of the dropped machine reminded me of a similar thing that happened in New England. I don't remember the company but Lou Fineli sold them a 3600/3670 and the customer decided they'd save a buck and truck it up from the airport themselves when it came in. Somehow when they were unloading it it fell off the truck ramp and skewed the entire rack several inches. Lou was happy because one sale netted him two commissions, one from the customer and one from the insurance company.
There was a show where I ran a demo suite and the sales guy asked me to set up a specific demo for a pet customer. I got it all set and he called housekeeping to vacuum and went to get the customer. Housekeeping came in, unplugged the running machine and plugged in her vacuum. I sat there slack jawwed and then suggested the sales guy take the customer for drinks, because I sure needed one.
Another conference was in Sioux Falls in a Howard Johnson's (the only facility in the area) and we got in late evening and spent until 2am getting the machines set up and working. Headed to bed and got back to the booth at 7:30 to find that the machines wouldn't boot. Turns out they had tapped into the dishwasher power to get us our power and the Fujitsu disk drive wouldn't spin up to speed because we were only seeing 70vac under load while the breakfast dishes were being done and the disk never came ready.
I suggest you read the article; it addresses this multiple times.
In brief, nobody's forcing anything on developers. It's just that the State is saying, hey, these are our requirements for what we buy, you meet them or we don't buy from you. Just like any other large customer.
I disagree. The arguments he makes are well-known, of course, but the way he makes them are extremely effective. They are made precisely the way that an (honest) politician in a country like Peru should be making arguments.
It's also excellent ways for other people to make arguments (or, more precisely, refutations). I intend to keep a copy of the (Congressman's) letter around, and send it to my non-technical friends who are confused about free software, because it's so instructive.
First, be sure you have something to hack! If you don't yet have a design ready, you have no business at a keyboard. Walk around the block, or sit down in the break room, or do something, but relax and meditate on your design. Don't compromise. You'll know the Right Thing when you have it. Then, you're ready to sit down and hack.
Now, on to the environmental issues.
Comfortable chair. I have an Aeron, and don't really see a difference between that and any other good computer chair.
No glare! At my last job, we were fanatical about closing the blinds when the sun started coming through them. (The window faces West.)
Low lighting. At work, after six, they turn off most of the lights. There's well enough light to be safe, but much less than normal in an office. Overhead florescents are evil. Eyestrain, flicker, icky things. With the low lighting, desk lamps are mandatory. Florescent is okay there, since it doesn't illuminate the monitor. Make sure the lights work properly. At home, I use a single 60w incandescent and a lava lamp.
Descent sized desk, with bookshelves. Being able to have schema diagrams, language references, etc. arrayed for easy reading while coding, without having to constantly shuffle things on your desk, is very important.
General ergonomic concerns. Don't make the coder uncomfortable if he's going to have his butt plastered to that chair for a while. As keyboards go, I can code longer with my Maltron than my QWERTY (yes, I've identified this as a trend), but this is more personal taste than anything else.
If your company tends towards phone over email, be sure to have a Do-Not-Disturb button on the phone! With all the biffs out there, there's no reason that somebody trying to concentrate can't put off a request for a half hour while they're juggling eggs. (My phone hasn't rung in some four months, so I don't even know if it has a DnD button. If it's urgent, you page me. If not, you email me.)
Music. I personally prefer Celtic, Metallica, 80's, or FPS soundtracks, but this is *so* personal, be sure to experiment and find what works for you. Wireless headphones are a Godsend in an office environment where speakers are unusable. Never get an MP3 player without a repeat-all function.
At home, I frequently hack well with the TV on. I leave shows I've already watched on the TiVo and put either them or a DVD on. It should be something you've recently seen. I also have good luck turning Emacs translucent and watching DVDs through it. Music video DVDs are great.
My company has free bottled water and a selection of juices and sodas, always stocked, on each floor. Very good. When you hack for six hours in a row, you can get dehydrated too easily. We save money on water by giving out bottles (in koozies so people keep them) and having coolers. Get out the bottle or can before you sit down to hack. And think about water instead of soda; it really does work! (And this is coming from a die-hard Coca-Cola addict!)
If you're close to a meal, consider postponing your hack session until after; catch up on email or fix some quick bugs first.
A lot of people have talked about screen real estate for lots of xterms. I don't get that. I have Emacs, and that's it. But I write a lot in Lisp, where 99% of your time can be spent in Emacs with an Emacs window on the Lisp interpreter, except for when you're doing GUI design. In fact, a lot of the time, I work in console mode instead, to get rid of distracting window manager stuff.
You demean all programmers by implying that there is no skill spread between them.
And any programmer who thinks that a Programming Methodology that was handed down from On High (defined as either somebody with an MBA or a PhD) is good for all things, is in the wrong line of work. It's a craft, not a skill.
And a "me too" going to anybody who thinks that timing can be used to avoid spoilers:
As for myself, I TiVo all my faves, and watch them when I have time. I very well may not watch one of my favorite shows for days, and in one case, weeks.
And I don't even know what the overseas situation is.
I'm specifically addressing the bit where the poster said: So the agree on a series of bits to encrypt with. This can be anything from "every other bit" to a large polynomial function that says which bits to use. So every bit the function designates as an encrypted bit is used to XOR any message Alice and Bob use to communitacte.
I'll go along with the idea that the bits from the satellite are indeed random. (I use this phrasing because I haven't verified it myself, but I have no qualms with the assertion for the purposes of this argument.) But those are common knowledge. They become part of the PRNG, a convolution matrix for the output of his "large polynomial function" or whatever the bit selection function is.
Consider these bits, from a physical RNG:
CB 57 DD F4 B1 91 F6 26
These represent some of the satellite bits.
Now, I have a polynomial ax^2+bx+c. (I'm not telling you (a,b,c), because that's my cipher key.) Take the output of that at 1,2,3.... Take those values mod 2. Obviously, you don't have a good RNG... it's pretty easy to predict. (The crypto connection here is that you then XOR these with your message.)
Next, take the same values, but instead of mod 2, take it mod 64; call that k. Take the k'th bit of the bits I gave you earlier.
If you know the bits, and I know the bits, then this is no more secure than the predictable RNG I hypothesized about earlier. We're just using a convolution matrix, but the matrix is part of the algorithm-- ie, common knowledge-- not part of the key.
You're making the same mistake that Precident made: the belief that any mathematical function can generate a random series of bits. The best you can do is pseudo-random. And using pseudo-random and thinking you've got an OTP is a very, very bad thing.
I don't care if you're using a satellite to create a convolution matrix, you're still using a mathematical function to generate the bits.
The satellite idea is based, pretty much, on the theory that "nobody can store all those bits for analysis". I won't discuss the practical merits of that, since/. already has. But it gives you no theoretical gain. You're stil l trying to call the output of a PRNG an OTP, and that just ain't so.
Slashdot Mirror
Nuts... Looks like I'll have to fix my code that uses 32-bit timestamps after all.
I've been making VCDs of my nephew. He lives in Texas and I live in California, so it's about the only involvement in his life that I have. I make these VCDs using only open-source tools (some of which I made for this purpose and haven't released quite yet).
I use VCDs because they're easy to make with a commodity burner, play on most DVD players, and are suitably versatile, compatible, and easy to use.
Now, it sounds like the following scenario is on the horizon:
Is this about right?
That's okay... I'm musically inclined and can still write songs I can send to him... except... gee, I just got a sense of deja vu.
If you don't know what a sysadmin goes through for you, look at:
Adminspotting
A Day in the Life of a Sysadmin
Sysadmin's voicemail
Just a note to wish you all a happy sysadmin appreciation day!
I know that I, like so many, make lots of random demands on your time and patience, and so frequently don't think about what you go through to keep our systems-- servers, workstations, labs, infrastructure, everything-- running smoothly.
So, for all the times I've forgotten, thank you.
Best,
joelh
In the past, I used Emacs's VC features extensively. (This is the front-end over version control systems.) Now, I use both PCVS (added in Emacs 21, takes advantage of CVS's features) and VC extensively.
It's great. I wanna work on a file? I open it, press C-x C-q to get the latest version. I edit it, then press C-x C-q again to check it in. If there was a conflict, I get an easy to use conflict resolution browser. I fix it, and commit again. I type in a log message (viewing the diffs to help me by pressing C-x v =), press C-c C-c, and I'm done. All that is under VC. It's easy as falling off a log.
PCVS adds the ability for me to quickly look over directories to see what the status of different files is. From there, I can mark files and perform batch updates.
Post-failure analysis is easy too. Annotate, diff, log, etc. are all available at the touch of a button while I'm editing the file in question. Nothing to it.
I see a lot of people who don't realize how easy these can make CVS to use. I use CVS all the time, and have no complaints.
What are you talking about? The closest thing to "smite the infidel" that Matthew 10 comes is in v14:
First off: never underestimate the value of putting research notes in your comments! A simple "This averages O(NlogN), but is worse if the data is presorted" can really make somebody's day.
Now, the long rambling description of how I like to see comments:
Every file should have, right after the boilerplate (after copyright, before #includes etc) a brief description of that file.
Name your functions something concise, and accurate, but not necessarily precise. You don't need sort-sequence-on-predicate when sort will do just as nicely.
The same goes for variables. Using i and j for numeric iterators is fine, but you rarely should use foo and bar. Most variables should also have a short (usually <20 char) comment, although globals should have a longer comment, possibly describing how they're used.
Every function should have a docstring. In some languages, such as C, this is normally comments at the beginning of the function. In some, such as Lisp, there are conventions for including the docstring in a manner that the compiler will recognize.
The first line of the docstring should be a self-contained sentence that tells what the function does. The rest can go into detail about how to call it. The purpose of this bit is "what does a caller of this function need to know". Wait on the implementation notes for now... we want the caller information to be all one, tidy package.
If your language does have docstring support (either directly or through an external tool), then implementation notes belong in comments, not the docstring. Either way, put them after the caller information, so that somebody who just wants to use your function doesn't need to read them.
As an extention of this idea, functions should begin with a brief overview of how they work. (For extremely simple functions, this may be omitted.) If the function implements a formal algorithm, such as a sort or hash algorithm, then a formal description is certainly not out of place, or give a reference. This is also a good place to note any behavorial characteristics.
Divide your code into "paragraphs", between 5 and 20 lines long. Skip a blank line between paragraphs. This also helps find areas that are good candidates for factoring out into separate functions.
Each paragraph may start with a block comment describing either what that paragraph does, or at least the program's state at that point in execution. Feel free to make these as descriptive as you like; they're the landmarks for somebody reading the code.
Loop guards frequently should have a one-line comment describing what they're testing for, in terms of the algorithm as a whole.
If a line's meaning isn't immediately clear, then clarify it with a one-liner.
Any one-liners may be expanded to multi-liners if you need to:
Mark areas that need investigation or more work with a comment of "FIXME"; that makes grepping later on much easier.
You can also use XXX for a similar purpose, or (what I do) to mark areas of grave significance.
Don't worry about descriptive comments being too verbose. Descriptions of program state, why something exists, research notes, or prose all have their place in comments. The only time I've read a file and thought "Gee, this is overcommented" was when it had template comments with changelogs and argument lists.
Now what do you not use comments for?
Don't keep a changelog in your code. Your source-control system does a much better job.
Don't repeat the argument list. The argument list itself does a perfectly fine job of that, and will always be up-to-date. If the purpose of each argument isn't clear by its name, then add a one-line comment to the arguments. (Note: In Perl, don't shift the arguments off as needed. Get all the arguments off in the first line of code if possible, such as my ($self,$filename,$options) = @_; in order to let somebody calling the function to have an argument list available!)
Don't document the language (eg, explaining ++). This not only is unhelpful, but distracts from useful comments. If somebody doesn't know what ++ does, they can look it up.
Credits: Examples snipped and adapted from my own development, as well as CMUCL and FreeBSD sources.
How do you figure Perl to be a security risk?
That's a good point. So, does anybody know where there's a good write-up on the importance of privacy and the dangers to it in the modern world?
There's several XMMS plugins that do this type of plot. The descriptions don't say whether they have a linear / log switch, though.
So what'd it say already?
Or, more succinctly (and, rather than targeting RR, shows the mistake in general):
I can't find my favorite (it's in a collection of computer horror stories I misplaced), but here's a few from old Symbolics lore. The first is available in a few places on the net, the second is probably only on SMBX.
T306 Tales
3600s Come to Austin War StoriesI got into programming because of an Atari 800 in my 3rd grade classroom. These days, I'm a professional programmer.
Computers stimulate the imagination, teach logic, etc, etc. I think having them in the classroom is a Good Thing.
I do think that having a computer boot up to Pilot, Logo, or some other programming language is a better thing than "Welcome to Windows 2000".
So, you're saying that only the guilty have something to hide?
I didn't; where did it say he wasn't a lawyer?
I suggest you read the article; it addresses this multiple times.
In brief, nobody's forcing anything on developers. It's just that the State is saying, hey, these are our requirements for what we buy, you meet them or we don't buy from you. Just like any other large customer.
Y'know, like a free market economy.
Because my Spanish isn't good enough. I grew up in Texas, so most of what I know is based around the Mexican idiom.
Can anybody who speaks Spanish well enough post a template for such a short, polite note of praise? I'd use Babelfish, but it seems somehow insulting.
I disagree. The arguments he makes are well-known, of course, but the way he makes them are extremely effective. They are made precisely the way that an (honest) politician in a country like Peru should be making arguments.
It's also excellent ways for other people to make arguments (or, more precisely, refutations). I intend to keep a copy of the (Congressman's) letter around, and send it to my non-technical friends who are confused about free software, because it's so instructive.
It's just that good.
You've never had to pay royalties, I take it?
Here's what I find works well.
First, be sure you have something to hack! If you don't yet have a design ready, you have no business at a keyboard. Walk around the block, or sit down in the break room, or do something, but relax and meditate on your design. Don't compromise. You'll know the Right Thing when you have it. Then, you're ready to sit down and hack.
Now, on to the environmental issues.
Comfortable chair. I have an Aeron, and don't really see a difference between that and any other good computer chair.
No glare! At my last job, we were fanatical about closing the blinds when the sun started coming through them. (The window faces West.)
Low lighting. At work, after six, they turn off most of the lights. There's well enough light to be safe, but much less than normal in an office. Overhead florescents are evil. Eyestrain, flicker, icky things. With the low lighting, desk lamps are mandatory. Florescent is okay there, since it doesn't illuminate the monitor. Make sure the lights work properly. At home, I use a single 60w incandescent and a lava lamp.
Descent sized desk, with bookshelves. Being able to have schema diagrams, language references, etc. arrayed for easy reading while coding, without having to constantly shuffle things on your desk, is very important.
General ergonomic concerns. Don't make the coder uncomfortable if he's going to have his butt plastered to that chair for a while. As keyboards go, I can code longer with my Maltron than my QWERTY (yes, I've identified this as a trend), but this is more personal taste than anything else.
If your company tends towards phone over email, be sure to have a Do-Not-Disturb button on the phone! With all the biffs out there, there's no reason that somebody trying to concentrate can't put off a request for a half hour while they're juggling eggs. (My phone hasn't rung in some four months, so I don't even know if it has a DnD button. If it's urgent, you page me. If not, you email me.)
Music. I personally prefer Celtic, Metallica, 80's, or FPS soundtracks, but this is *so* personal, be sure to experiment and find what works for you. Wireless headphones are a Godsend in an office environment where speakers are unusable. Never get an MP3 player without a repeat-all function.
At home, I frequently hack well with the TV on. I leave shows I've already watched on the TiVo and put either them or a DVD on. It should be something you've recently seen. I also have good luck turning Emacs translucent and watching DVDs through it. Music video DVDs are great.
My company has free bottled water and a selection of juices and sodas, always stocked, on each floor. Very good. When you hack for six hours in a row, you can get dehydrated too easily. We save money on water by giving out bottles (in koozies so people keep them) and having coolers. Get out the bottle or can before you sit down to hack. And think about water instead of soda; it really does work! (And this is coming from a die-hard Coca-Cola addict!)
If you're close to a meal, consider postponing your hack session until after; catch up on email or fix some quick bugs first.
A lot of people have talked about screen real estate for lots of xterms. I don't get that. I have Emacs, and that's it. But I write a lot in Lisp, where 99% of your time can be spent in Emacs with an Emacs window on the Lisp interpreter, except for when you're doing GUI design. In fact, a lot of the time, I work in console mode instead, to get rid of distracting window manager stuff.
You demean all programmers by implying that there is no skill spread between them.
And any programmer who thinks that a Programming Methodology that was handed down from On High (defined as either somebody with an MBA or a PhD) is good for all things, is in the wrong line of work. It's a craft, not a skill.
And a "me too" going to anybody who thinks that timing can be used to avoid spoilers:
As for myself, I TiVo all my faves, and watch them when I have time. I very well may not watch one of my favorite shows for days, and in one case, weeks.
And I don't even know what the overseas situation is.
For Pete's sake, Chris, don't try to schedule.
I'm specifically addressing the bit where the poster said: So the agree on a series of bits to encrypt with. This can be anything from "every other bit" to a large polynomial function that says which bits to use. So every bit the function designates as an encrypted bit is used to XOR any message Alice and Bob use to communitacte.
I'll go along with the idea that the bits from the satellite are indeed random. (I use this phrasing because I haven't verified it myself, but I have no qualms with the assertion for the purposes of this argument.) But those are common knowledge. They become part of the PRNG, a convolution matrix for the output of his "large polynomial function" or whatever the bit selection function is.
Consider these bits, from a physical RNG: CB 57 DD F4 B1 91 F6 26 These represent some of the satellite bits.
Now, I have a polynomial ax^2+bx+c. (I'm not telling you (a,b,c), because that's my cipher key.) Take the output of that at 1,2,3.... Take those values mod 2. Obviously, you don't have a good RNG... it's pretty easy to predict. (The crypto connection here is that you then XOR these with your message.)
Next, take the same values, but instead of mod 2, take it mod 64; call that k. Take the k'th bit of the bits I gave you earlier.
If you know the bits, and I know the bits, then this is no more secure than the predictable RNG I hypothesized about earlier. We're just using a convolution matrix, but the matrix is part of the algorithm-- ie, common knowledge-- not part of the key.
BZZT, wrong, but thanks for playing.
You're making the same mistake that Precident made: the belief that any mathematical function can generate a random series of bits. The best you can do is pseudo-random. And using pseudo-random and thinking you've got an OTP is a very, very bad thing.
I don't care if you're using a satellite to create a convolution matrix, you're still using a mathematical function to generate the bits.
The satellite idea is based, pretty much, on the theory that "nobody can store all those bits for analysis". I won't discuss the practical merits of that, since /. already has. But it gives you no theoretical gain. You're stil l trying to call the output of a PRNG an OTP, and that just ain't so.