> Or.. they will find a huge golden phallic symbol and be totally embarassed trying to work around it on live tv. In a way, it would be the ancients' way of giving us the finger.
> A previous attempt to penetrate the mysterious shaft ended in disappointment when it was discover that Lara Croft's cross-section was too large to permit her entry into the shaft.
Yeah, but the cameraman sure got some good shots while she was stuck.
>...wouldn't you want it to happen in front of all the students? Of course not. You do it at the time when there are the least amount of people on campus (and practically no students), right before the fall term, after summer exams are over.
For those who have never been to college, be aware that universities are notorious for announcing and implementing all manner of policy changes at that time. My alma did it to me several times.
Re: Agree: Time Travel, Holodeck, and Q plots suck
on
Star Trek: Pick A Plot
·
· Score: 1
> Extending the technology by introducing the Doctor in Voyager seemed okay
The whole Doctor thing looked to me like the screenwriters watched Red Dwarf, didn't realize it was a sitcom, and decided to imitate it.
FWIW, I have a friend who has been totally blind since birth, and I had the privilege of helping him get started with UNIX. I have also watched him work with his reader (human) on a college programming assignment, and it's a thing both amazing and inspiring to watch.
> Oh, and imagine a nationwide Beowulf cluster of these.
Actually, it might be a good way to set up a disaster-resistant beowulf cluster. One node per bunker, interconnect via the towers. Keep those protein-folding analyses running even after the species is extinct...
Well, at least it would give the alien archaeologists something interesting to puzzle over. And introduce them to the idea of beowulf clusters, so the joke could infect their civilization as well.
> 3) It will work like a Votematic punch card machine, but instead of punching holes in the ballot sheet there is enough area exposed on the ballot where you mark off your choice with a small ink stamp.
Better yet, just get punching bags printed with the various candidates' faces on them, and have the citizens walk by and punch a bag for each office. All the technology you'd need is a counter to show which bag for each race was punched the fewest times.
> Skepticism is irrelevant... it *did* work. I believe it simply checked the name of the output file... if it was creating an output target called 'gcc' (or the equivalent, whatever it had back then) then it compiled in the hack. I do not know how robust it was, but from what I remember reading, it worked, so it was obviously robust enough.
There's a big difference between working for a demo and working in the face of active countermeasures by a well-informed security administrator. In the example you cite, it would be sufficient for the SA to rename the source file before compiling it.
Also, notice that I'm not offering "skepticism" as "proof" of anything. I am skeptical that it would work in practice for very long against even fairly trivial countermeasures, but you'll notice that part of my post was an analysis of what it would take to make it work in the face of countermeasures on the user's part.
It looks to me like the basic requirement is "a very stable block of code that is only used in this compiler". And the result is probablistic, since we all know what "very stable block of code" means in practice. But presumably you could hide it fairly well if you could limit both detection and trojanized output to a single function, so that arbitrary changes elsewhere in the code would neither give a false trigger of the trojan nor disable it during ordinary maintenance. But even then there could be detections, e.g. if I decided to hack gcc to write a Pascal compiler and got stangeness in the output.
What would be fun, as well as educational, would be to get volunteers to form a Red team and a Blue team, to see whether the Red team could design such a compiler that the Blue team couldn't trip up, and vice versa. I would probably bet on Blue, though that might depend on the details of the rules of the game.
> The original vulnerability analysis inspired the self-inserting compiler back door described by Ken Thompson in his Turing Award Lecture.
This is a nifty concept, but I remain skeptical that it would ever work in practice, at least for an open-source produce such as gcc.
For starts, the compiler would have to detect that it was compiling itself. I.e., if you compile your favorite flight similator and the resulting program is a compiler rather than a flight simulator, the game is up already.
But recognizing itself isn't going to be such an easy task. For instance, if it just compressed the input and compared the result to a saved target, you could easily defeat it by something as simple as changing the names of identifiers in the source code. (If the match was done on just part of the code, you would merely need to do global string substitutions on the identifiers.)
So AFAICT, the trojan would have to identify itself by looking at the structure or semantics of the source file. But that's going to be tricky too. If I add a feature to the compiler or fix a bug in it, recompile, and discover that the feature is missing or the bug is still present, the game is up (after a bit of vigorous head-scratching). So it looks to me like the trojan must not only detect structure or semantics reliably, it must also limit detection to a very small block of code, to reduce the risk that it will be modified and break the trojan. That block of code must be specific enough that the trojan is never triggered when compiling other programs, and non-arbitrary enough that no one will re-write it in a zeal of code clean-up.
And, as others have pointed out in the past, the trojan has no way of slipping past if you use another compiler to compile it with. Even with two untrusted compilers, you can get a clean compile so long as the two compilers don't support each others' trojans.
> Is this award named after the A.I. theoretician?
s/A.I. theoretician/computer scientist/
He did have an influence on AI (cf. "Turing test") and on the more general concept of intelligence-as-computation (whether natural or artificial), but we generally think of him for his more fundamental contributions to computer science (cf. "Turing machine").
So you've been doing assembly for well-designed modern architectures and now you want to learn it for that bit of kludgery we call "x86"? My advice is to run your brain through a kitchen blender and then pour it back into your head. The x86 architecture may start making sense after that.
> Speaking as someone with some scientific background and an interest in religion, it's somewhat irritating when people consistently bleat about how science has proved various things like Earth being however many billion years old. No, it hasn't - and it can't, by definition, because it can't observe or repeat it - it's merely that the current theories, which seem to hold water at the moment, suggest that that's true. But the whole foundation for the theories can be a bit like a house of cards at times.
And of course the mythologies competing with science in these areas have no foundation at all.
> For methods beyond that, we start using methods that basically say "as long as our theories about how such and such behaves turn out to be true, this method of determining stellar distance should hold true."
I can tell from your other comments that you're not just trashing science, but for the benefit of any jerky knees in the audience I'd like to point out that that's how everything works, whether we're pushing the limits of what science can tell us about the universe or merely trying to design a better mousetrap. At some point you've just got to go with what you think you know, and be willing to make corrections later if that's how things turn out.
Slashdot Mirror
> He was also totally reckless with the artifacts, are there so many in Egypt that they don't bother being careful any more?
I saw a documentary once that claimed that there were so many mummies that they used to burn them for fuel in locomotives.
> Or.. they will find a huge golden phallic symbol and be totally embarassed trying to work around it on live tv. In a way, it would be the ancients' way of giving us the finger.
'Finger'?
> Alternatively, it could just be bullshit.
But the amazing thing is that all the bullshit got out before they opened the little door! At least Pandora had to open the box first.
> A previous attempt to penetrate the mysterious shaft ended in disappointment when it was discover that Lara Croft's cross-section was too large to permit her entry into the shaft.
Yeah, but the cameraman sure got some good shots while she was stuck.
> Former Astronaut, "Buzz" Aldrin seems to have suffered no ill effects or brain injury from high Gs from his flights and space shots.
Yeah, but the kook reportedly suffered somewhat from the law of conservation of momentum.
>
For those who have never been to college, be aware that universities are notorious for announcing and implementing all manner of policy changes at that time. My alma did it to me several times.
> Extending the technology by introducing the Doctor in Voyager seemed okay
The whole Doctor thing looked to me like the screenwriters watched Red Dwarf, didn't realize it was a sitcom, and decided to imitate it.
> Well, if you really want to admit it, there are only about three plots. You have Man against Nature, Man against Man and Man against Himself.
You missed the most popular plot of all time:
when written by non-geeks about an open-source product. (Remember that next time someone claims that open source only imitates, never innovates.)It certainly warms my heart to read -
BTW, there's an AFB announcement here.
FWIW, I have a friend who has been totally blind since birth, and I had the privilege of helping him get started with UNIX. I have also watched him work with his reader (human) on a college programming assignment, and it's a thing both amazing and inspiring to watch.
> Oh, and imagine a nationwide Beowulf cluster of these.
Actually, it might be a good way to set up a disaster-resistant beowulf cluster. One node per bunker, interconnect via the towers. Keep those protein-folding analyses running even after the species is extinct...
Well, at least it would give the alien archaeologists something interesting to puzzle over. And introduce them to the idea of beowulf clusters, so the joke could infect their civilization as well.
> I say setup a decent 'net connection and become a digital hermit.
Yeah, you could download a lot of porn over one of those receivers!
> How could you trust someone with the most powerful military in the world when he ran to Canada like a coward
And where did our current War Hero In Chief run to?
Whew. Do you have any advice about what text should be bold on the ballots?
> 3) It will work like a Votematic punch card machine, but instead of punching holes in the ballot sheet there is enough area exposed on the ballot where you mark off your choice with a small ink stamp.
Better yet, just get punching bags printed with the various candidates' faces on them, and have the citizens walk by and punch a bag for each office. All the technology you'd need is a counter to show which bag for each race was punched the fewest times.
Nope, 'hypocrosy' is when your lower pair of eyeballs are crossed.
I thought it was the 38 Special that democratized taking credit cards.
> "a lot" is two words, damnit!
Yeah, I was going to suggest that he start with and English book, and read the physics book later.
> Skepticism is irrelevant... it *did* work. I believe it simply checked the name of the output file... if it was creating an output target called 'gcc' (or the equivalent, whatever it had back then) then it compiled in the hack. I do not know how robust it was, but from what I remember reading, it worked, so it was obviously robust enough.
There's a big difference between working for a demo and working in the face of active countermeasures by a well-informed security administrator. In the example you cite, it would be sufficient for the SA to rename the source file before compiling it.
Also, notice that I'm not offering "skepticism" as "proof" of anything. I am skeptical that it would work in practice for very long against even fairly trivial countermeasures, but you'll notice that part of my post was an analysis of what it would take to make it work in the face of countermeasures on the user's part.
It looks to me like the basic requirement is "a very stable block of code that is only used in this compiler". And the result is probablistic, since we all know what "very stable block of code" means in practice. But presumably you could hide it fairly well if you could limit both detection and trojanized output to a single function, so that arbitrary changes elsewhere in the code would neither give a false trigger of the trojan nor disable it during ordinary maintenance. But even then there could be detections, e.g. if I decided to hack gcc to write a Pascal compiler and got stangeness in the output.
What would be fun, as well as educational, would be to get volunteers to form a Red team and a Blue team, to see whether the Red team could design such a compiler that the Blue team couldn't trip up, and vice versa. I would probably bet on Blue, though that might depend on the details of the rules of the game.
> The original vulnerability analysis inspired the self-inserting compiler back door described by Ken Thompson in his Turing Award Lecture.
This is a nifty concept, but I remain skeptical that it would ever work in practice, at least for an open-source produce such as gcc.
For starts, the compiler would have to detect that it was compiling itself. I.e., if you compile your favorite flight similator and the resulting program is a compiler rather than a flight simulator, the game is up already.
But recognizing itself isn't going to be such an easy task. For instance, if it just compressed the input and compared the result to a saved target, you could easily defeat it by something as simple as changing the names of identifiers in the source code. (If the match was done on just part of the code, you would merely need to do global string substitutions on the identifiers.)
So AFAICT, the trojan would have to identify itself by looking at the structure or semantics of the source file. But that's going to be tricky too. If I add a feature to the compiler or fix a bug in it, recompile, and discover that the feature is missing or the bug is still present, the game is up (after a bit of vigorous head-scratching). So it looks to me like the trojan must not only detect structure or semantics reliably, it must also limit detection to a very small block of code, to reduce the risk that it will be modified and break the trojan. That block of code must be specific enough that the trojan is never triggered when compiling other programs, and non-arbitrary enough that no one will re-write it in a zeal of code clean-up.
And, as others have pointed out in the past, the trojan has no way of slipping past if you use another compiler to compile it with. Even with two untrusted compilers, you can get a clean compile so long as the two compilers don't support each others' trojans.
> Is this award named after the A.I. theoretician?
s/A.I. theoretician/computer scientist/
He did have an influence on AI (cf. "Turing test") and on the more general concept of intelligence-as-computation (whether natural or artificial), but we generally think of him for his more fundamental contributions to computer science (cf. "Turing machine").
> I like the idea of forwarding the spam, but the question remains what will they do with it?
They're just looking for good deals on toner cartridges.
> Next thing I know, someone is going to try programming the database in perl.
Shucks... I saw your subject line, "all 889,063,398,406 positions", and clicked it expecting to see recommendations for full-coverage sex manuals.
So you've been doing assembly for well-designed modern architectures and now you want to learn it for that bit of kludgery we call "x86"? My advice is to run your brain through a kitchen blender and then pour it back into your head. The x86 architecture may start making sense after that.
> Speaking as someone with some scientific background and an interest in religion, it's somewhat irritating when people consistently bleat about how science has proved various things like Earth being however many billion years old. No, it hasn't - and it can't, by definition, because it can't observe or repeat it - it's merely that the current theories, which seem to hold water at the moment, suggest that that's true. But the whole foundation for the theories can be a bit like a house of cards at times.
And of course the mythologies competing with science in these areas have no foundation at all.
I fear you have completely missed my point.
> For methods beyond that, we start using methods that basically say "as long as our theories about how such and such behaves turn out to be true, this method of determining stellar distance should hold true."
I can tell from your other comments that you're not just trashing science, but for the benefit of any jerky knees in the audience I'd like to point out that that's how everything works, whether we're pushing the limits of what science can tell us about the universe or merely trying to design a better mousetrap. At some point you've just got to go with what you think you know, and be willing to make corrections later if that's how things turn out.