Apart from the now old-school Lisp OS: http://common-lisp.net/project/movitz/
there is someone who's working on booting SBCL cores directly with the bootloader in Forth) [it boots, but the cross-compiler has some issues]
there's a version of smalltalk (of squeak?) that runs without any underlying OS.
There were several lisp or scheme *chips* in the 70s and 80s.
Also, what exactly do you see in common between Java and Haskell?
Finally, how in the world is that comment even slightly interesting?
You'll want to make sure that the new system interacts correctly and usefully with the hotel's phone system. Depending on that system, it could reduce the number of choices rather dramatically.
Actually, we do need more info to know whether the difference was significative or not. The article doesn't give us the probability that the difference isn't significative, and we'd have to know (at least) the standard deviations and the averages for the different groups to have a shot at estimating that.
erh... Lessee. It's open sourced... And it's fricken programmable? Is your IM explicitly designed to allow you to write your own agents? (Also, OMG! Alan Kay is in there).
Or, potentially more simply, speculatively execute both branches and only commit the changes from cache (and kill the mispredicted thread) when the branch has been resolved. Things become easier to safely multi-thread when mutable state isn't shared. *cough* FP *cough*;)
Mm. no. If the hash really is good, it'll yield ~16 new bits of information re the sum / hash. Hence the 4 different challenges, each allowing you to recover ~ 16 of the 56 bits.
Well, the hash is lossy (56 -> 16 bits, iirc), so you'd probably need ~4 attempts of the same challenge with 4 different seeds to recover the sum. Still very much in the realm of the doable.
Re:Stuff I didn't get from TA
on
DNA Origami
·
· Score: 1
The AC (parent) is informative. Mod him up.
1. "I didn't read the actual Nature article, but it seems likely that the staples serve to stabilize long portions and force 180 degree turns at the necessary locations on the long DNA strand." I've skimmed the article (hopefully, the next comment will be by someone who's actually read the article), and, IIUC, the staples reduce the complexity of knowing how the DNA will fold (wrt secondary structure). Other approaches use superclean strands. This one simply adds the number of known/highly probable points.
4. Actually, I think it might be possible to use them directly to compute. Either like mechanical devices, or through some other, more freeform, interaction between elements. Conway's Game of Life is Turing complete; I'd be surprised if it was impossible to make shaped-DNA compute:)
Don't hide right in a corner, then. Camp just off corners and other natural camping spots instead. There isn't any substantial tactical difference, and people shooting at the usualy camping spots won't hit you, or only your limbs.
I've also implemented a simple double double (represents numbers as an unevaluated sum of two non-overlapping doubles) arithmetic in CL. It was ~25% as fast as doubles (mostly branchless, each op expands into ~2-8 double precision op). That gives an upper-bound on the slowdown ratio for the emulation of doubles with singles.
Yeah, I think the USB exploits rely on shoddy driver programming by EEs. Exploiting drivers can be pretty scarily powerful, and those who write them often don't have a huge secure programming background.
USB and Firewire allow devices to peek/poke through (physical) memory at will. With the iPod, we have a device that's:
1. Can be attached to a computer without being suspect 2. Can run Linux with programs of your choice 3. Has a built-in mass storage system
Any open USB/Firewire port is a potentially huge threat to your whole system's security. If you look here: http://www.cansecwest.com/resources.html, you'll find a pretty detailed presentation on using iPodLinux to hack a computer (kill an X Window screensaver, here) through firewire, and another less detailed one on other DMA-attack vectors (PCMCIA and USB, mostly, iirc). So while it looks like this attack only uses characteristics 1 and 3 of the iPod, the second one is where the money's at (and requires a much larger investment).
In short, have each component loosely coupled with the whole system, and make each component crash and restart (to a recent good state) on failure. When shit happens the whole system can go on working, and the component that crashed resumes work quickly.
Topic says it all. Different pH, temperature, humidity,... Bacteria, fungi (etc) that thrive in the ground usually don't like it as much in a hot, warm and nearly neutral human body. We don't have a lot of things that work very well on fungi (heck, most of our antibiotics come from fungi), but they don't represent a large danger, simply because our insides are usually a bit too warm for them. Let's not panic too early.
"Again, in the C compiler, Figure 5 represents the high-level control of the C compiler where the routine "compile" is called to compile the next line of source. Figure 6 shows a simple modification to the compiler that will deliberately miscompile source whenever a particular pattern is matched. If this were not deliberate, it would be called a compiler "bug." Since it is deliberate, it should be called a "Trojan horse." "
Yes, this is the exact paper Wheeler (and probably the great grandparent, implicitly) refers to. Yes, it was in 1984. Yes it was practical enough back then that it was actually done. Yes, it would still be practical today.
Note that this is not what Wheeler's paper is about. Wheeler's paper is about knowing when such a trojan has been implanted in the binary compiler (which then propagates it whenever it compiles itself).
"Excuse me? Why would the CISC frontend allow better ultilization of cache resources?"
Because the encoding is more compact. For example, compare adding or loading a 32 bit immediate in x86 to the same in any 32bit "RISC". It's widely known and accepted that CISCy encoding reduces the pressure on the I-cache (yes, not for the L1 I-cache on the P4, since the instructions are stored in a decoded form). There has been research into compressing the instruction stream (huffmann, gzip,...), but I don't know if it's yielded anything in recent years.
"But assumed that a possible benefit in the CISC frontend exists (apart from more compact code on average, that is) -- what difference does it make in terms of bus accesses when the CISC commands get recoded into CISC instructions anyway? Any optimization which was done by (a) the compiler on the CISC frontend and (b) by the internal OoO scheduler on the uOps kan be done as well on native RISC ops."
That was not the grandparent's point. His point was that while, as we seem to agree, CISC offers a more compact encoding, it doesn't suffer from the encoding's complexity much, since they are decoded back in a RISCy form. In other words, the gp was not saying that decoding gives an edge to CISC, but that it allows one to use a CISC encoding while still enjoying RISC's advantages later in the pipeline. As chips are getting more and more complex, adding more logic to reduce bus pressure (or perform runtime optimisations... *cough* EPIC *cough*;) seems less and less costly.
Countering Trusting Trust through Diverse Double-Compiling
David A. Wheeler Institute for Defense Analyses USA
An Air Force evaluation of Multics, and Ken Thompson's famous Turing award lecture "Reflections on Trusting Trust," showed that compilers can be subverted to insert malicious Trojan horses into critical software, including themselves. If this attack goes undetected, even complete analysis of a system's source code will not find the malicious code that is running, and methods for detecting this particular attack are not widely known. This paper describes a practical technique, termed diverse double-compiling (DDC), that detects this attack and some unintended compiler defects as well. Simply recompile the purported source code twice: once with a second (trusted) compiler, and again using the result of the first compilation. If the result is bit-for-bit identical with the untrusted binary, then the source code accurately represents the binary. This technique has been mentioned informally, but its issues and ramifications have not been identified or discussed in a peer-reviewed work, nor has a public demonstration been made. This paper describes the technique, justifies it, describes how to overcome practical challenges, and demonstrates it.
Slashdot Mirror
Who pages to *flash*?
No, he resigned from GOOG (his last employer, afaik) some time ago.
Apart from the now old-school Lisp OS:
http://common-lisp.net/project/movitz/
there is someone who's working on booting SBCL cores directly with the bootloader in Forth) [it boots, but the cross-compiler has some issues]
there's a version of smalltalk (of squeak?) that runs without any underlying OS.
There were several lisp or scheme *chips* in the 70s and 80s.
Also, what exactly do you see in common between Java and Haskell?
Finally, how in the world is that comment even slightly interesting?
More like
1. Move around
2. Make a creature
2. Move around
3. Change your creature
4. Play civ
5. play sim earth
6. play sim galaxy
You'll want to make sure that the new system interacts correctly and usefully with the hotel's phone system. Depending on that system, it could reduce the number of choices rather dramatically.
Actually, we do need more info to know whether the difference was significative or not. The article doesn't give us the probability that the difference isn't significative, and we'd have to know (at least) the standard deviations and the averages for the different groups to have a shot at estimating that.
erh... Lessee. It's open sourced... And it's fricken programmable? Is your IM explicitly designed to allow you to write your own agents? (Also, OMG! Alan Kay is in there).
At least do some research before flaming.
Or, potentially more simply, speculatively execute both branches and only commit the changes from cache (and kill the mispredicted thread) when the branch has been resolved. Things become easier to safely multi-thread when mutable state isn't shared. *cough* FP *cough* ;)
Mm. no. If the hash really is good, it'll yield ~16 new bits of information re the sum / hash. Hence the 4 different challenges, each allowing you to recover ~ 16 of the 56 bits.
Well, the hash is lossy (56 -> 16 bits, iirc), so you'd probably need ~4 attempts of the same challenge with 4 different seeds to recover the sum. Still very much in the realm of the doable.
What about a computer in your fiber?
:)
Now that would be hot
The AC (parent) is informative. Mod him up.
:)
1. "I didn't read the actual Nature article, but it seems likely that the staples serve to stabilize long portions and force 180 degree turns at the necessary locations on the long DNA strand." I've skimmed the article (hopefully, the next comment will be by someone who's actually read the article), and, IIUC, the staples reduce the complexity of knowing how the DNA will fold (wrt secondary structure). Other approaches use superclean strands. This one simply adds the number of known/highly probable points.
4. Actually, I think it might be possible to use them directly to compute. Either like mechanical devices, or through some other, more freeform, interaction between elements. Conway's Game of Life is Turing complete; I'd be surprised if it was impossible to make shaped-DNA compute
Don't hide right in a corner, then. Camp just off corners and other natural camping spots instead. There isn't any substantial tactical difference, and people shooting at the usualy camping spots won't hit you, or only your limbs.
see topic.
A "gradient of one in two" is a dimensionless ratio. A slope is the mathematical slope in %, which, again, is a dimensionless ratio.
SPARCv8(?) and up have quad precision.
I've also implemented a simple double double (represents numbers as an unevaluated sum of two non-overlapping doubles) arithmetic in CL. It was ~25% as fast as doubles (mostly branchless, each op expands into ~2-8 double precision op). That gives an upper-bound on the slowdown ratio for the emulation of doubles with singles.
Yeah, that's exactly what I suggested :) It's an effective, cheap, low-tech solution. Ig might even be patent unencumbered! What's not to love?
Yeah, I think the USB exploits rely on shoddy driver programming by EEs. Exploiting drivers can be pretty scarily powerful, and those who write them often don't have a huge secure programming background.
USB and Firewire allow devices to peek/poke through (physical) memory at will. With the iPod, we have a device that's:
1. Can be attached to a computer without being suspect
2. Can run Linux with programs of your choice
3. Has a built-in mass storage system
Any open USB/Firewire port is a potentially huge threat to your whole system's security. If you look here: http://www.cansecwest.com/resources.html, you'll find a pretty detailed presentation on using iPodLinux to hack a computer (kill an X Window screensaver, here) through firewire, and another less detailed one on other DMA-attack vectors (PCMCIA and USB, mostly, iirc). So while it looks like this attack only uses characteristics 1 and 3 of the iPod, the second one is where the money's at (and requires a much larger investment).
Fill those ports with cement!
In short, have each component loosely coupled with the whole system, and make each component crash and restart (to a recent good state) on failure. When shit happens the whole system can go on working, and the component that crashed resumes work quickly.
c.f. http://crash.stanford.edu/
Erh, yeah... It seems the comment was in jest, but you'd be surprised.
Topic says it all. Different pH, temperature, humidity, ... Bacteria, fungi (etc) that thrive in the ground usually don't like it as much in a hot, warm and nearly neutral human body. We don't have a lot of things that work very well on fungi (heck, most of our antibiotics come from fungi), but they don't represent a large danger, simply because our insides are usually a bit too warm for them. Let's not panic too early.
You don't know your history.
"Reflections on Trusting Trust
Ken Thompson
Reprinted from Communication of the ACM, Vol. 27, No. 8, August 1984, pp. 761-763."
http://www.acm.org/classics/sep95/
"Again, in the C compiler, Figure 5 represents the high-level control of the C compiler where the routine "compile" is called to compile the next line of source. Figure 6 shows a simple modification to the compiler that will deliberately miscompile source whenever a particular pattern is matched. If this were not deliberate, it would be called a compiler "bug." Since it is deliberate, it should be called a "Trojan horse." "
Yes, this is the exact paper Wheeler (and probably the great grandparent, implicitly) refers to. Yes, it was in 1984. Yes it was practical enough back then that it was actually done. Yes, it would still be practical today.
Note that this is not what Wheeler's paper is about. Wheeler's paper is about knowing when such a trojan has been implanted in the binary compiler (which then propagates it whenever it compiles itself).
"Excuse me? Why would the CISC frontend allow better ultilization of cache resources?"
...), but I don't know if it's yielded anything in recent years.
;) seems less and less costly.
Because the encoding is more compact. For example, compare adding or loading a 32 bit immediate in x86 to the same in any 32bit "RISC". It's widely known and accepted that CISCy encoding reduces the pressure on the I-cache (yes, not for the L1 I-cache on the P4, since the instructions are stored in a decoded form). There has been research into compressing the instruction stream (huffmann, gzip,
"But assumed that a possible benefit in the CISC frontend exists (apart from more compact code on average, that is) -- what difference does it make in terms of bus accesses when the CISC commands get recoded into CISC instructions anyway? Any optimization which was done by (a) the compiler on the CISC frontend and (b) by the internal OoO scheduler on the uOps kan be done as well on native RISC ops."
That was not the grandparent's point. His point was that while, as we seem to agree, CISC offers a more compact encoding, it doesn't suffer from the encoding's complexity much, since they are decoded back in a RISCy form. In other words, the gp was not saying that decoding gives an edge to CISC, but that it allows one to use a CISC encoding while still enjoying RISC's advantages later in the pipeline. As chips are getting more and more complex, adding more logic to reduce bus pressure (or perform runtime optimisations... *cough* EPIC *cough*
You can test the compiler's trustworthiness.
http://www.acsa-admin.org/2005/abstracts/47.html
Countering Trusting Trust through Diverse Double-Compiling
David A. Wheeler
Institute for Defense Analyses
USA
An Air Force evaluation of Multics, and Ken Thompson's famous Turing award lecture "Reflections on Trusting Trust," showed that compilers can be subverted to insert malicious Trojan horses into critical software, including themselves. If this attack goes undetected, even complete analysis of a system's source code will not find the malicious code that is running, and methods for detecting this particular attack are not widely known. This paper describes a practical technique, termed diverse double-compiling (DDC), that detects this attack and some unintended compiler defects as well. Simply recompile the purported source code twice: once with a second (trusted) compiler, and again using the result of the first compilation. If the result is bit-for-bit identical with the untrusted binary, then the source code accurately represents the binary. This technique has been mentioned informally, but its issues and ramifications have not been identified or discussed in a peer-reviewed work, nor has a public demonstration been made. This paper describes the technique, justifies it, describes how to overcome practical challenges, and demonstrates it.
Nope, we're still one of the 2-3 places in the world to tax our taxes.