I expect that he merely adds some salt, encrypts that + the one-time-pad in one of the stream modes (CFB?), and uses THAT as the "session OTP" for the message.
Security in this case would be equivalent to the encryption used to generate the session OTP, not the provable security of the a true OTP.
I think schneier was the one to point out that we are all able to invent ciphers that we can't break ourselves. The good ciphers are the ones that can't be broken by others.
If you're into building from components, I'd suggest picking up a pre-hacked i-opener from ebay (expect to pay ~ $70-100 +s/h depending on size of included hd and quality of work).
The midori for iopener image (see google for url) gives you a web browser, xmms, and a linux kernel that can drive: kawasaki/pegasus based usb ethernet; linksys wusb11v2.5 (important about the v number. 2.6 is in stores now, and won't work) 802.11b; usb audio out.
The i-opener comes with an acceptable 800x600 lcd and a crappy ps/2 keyboard+mouse combo.
So you can start cheap and use the built in audio and a netgear ea101 for ~ $100 (NB: the iopener doesn't have audio out, so that has to be hacked in. Trivial hack, but needs to be done if you don't want to use usb audio) and grow it to have wireless network and spdif output for another $100, when you feel you want that.
The only drawback is that I haven't figured out how to turn off the backlight (or more accurately, turn it back on again), but the thing boots to xmms in about a minute, so that's not a killer.
beetles are funny. I still smile at the story (told by gould?) about the zoologist asked what his work could tell us about god (this was in the times when this was conscidered a meaningful question).
his answer: "He must have an inordinate fondness for beetles."
actually an old colleague of mine had the opinion that functional languages weren't _inherently_ more productive, but _did_ tend to attract programmers who understood abstraction at a deep level.
these guys can write good code in _any_ language (he was a scheme hacker who was busy optimising HAIRY C gc code), but are attracted to functional langs because such langs directly capture the abstractions these guys use.
so, to paint with a broad brush, functional languages aren't nec. better than imperative, but the functional paradigm (abstraction, genericity, focussing on data rather than process) IS.
no, the killer is that the kernel headers aren't installed by default --- or maybe not the headers, but whatever the advanced 3rd party kernel modules like gatos and linux-wlan-ng need in order to configure themselves.
I've never needed to recompile the kernel, but I have needed to find and install the kernel sources (for rh 7.2) in order to compile modules.
but you want me to pay your expensive lawyer too!? that should come out of your winnings. Else we are basically giving the lawyer the right to assess damages me as well, but without any legal guidelines as to the ammount.
Seems fairer to me that the suit bringer always pays his lawyer, and also the defendant's, if the suit is overturned.
That way, people only sue if they are sure to win, and rich people or companies can't sue poorer people just to harass them into settling out of court.
And there's no risk in sticking your neck out if you know you are right.
those cooling lasers work like throwing marbles at a bowling ball to control its motion (ie, rather than moving just energy, you need to fiddle with momentum).
The cool bit is that the lasers are tuned so that doppler shift decides whether the atom absorbs a photon (is hit by a marble) or not.
You may want to conscider the meaning of the word "internal". Of course the emulator wouldn't expose the internal instruction set. That's the whole point of an emulator: get the same result by different implementation. The internal risc ops are an implemenation hack. I thought this came through in my post.
my GUESS is that the opteron line has two instruction sets: the normal x86 compatibilty instructions, and the native amd internal 64 bit instructions that the x86s are translated to.
Almost all high performance x86 compatible chips run another instruction set internally, because the x86 is just to damn weird. The translation happens transparently.
However, given that AMD will have put alot of effort into said translation, I don't see that going to plain x86 and thereby being able to reuse all the mature tools for that instruction set as being too stupid a move.
orbit goes really well with the bumblebee gtk theme
Re:Some things I've come across before today:
on
When Users Attack
·
· Score: 1
crap! ended up in the wrong thread.
What I wanted to say here was that I'd be _real_ worried if any hard-drive were susceptible to a holistic bracelet's magnets. I mean magnetic fields decay as the square of the distance, and the magnets inside the drive are 1) strong as fuck, and b) _really_ close to the platter.
Re:Some things I've come across before today:
on
When Users Attack
·
· Score: 2, Interesting
I seem to recall a story about the MIT AI lab having an old machine with a "magic" switch. The machine _would not run_ wihtout magic turned on.
Ok. cute, you think. Someone has wired the "magic" to control the power supply.... nope.
On opening the case, there is only one (1) conductor going from the switch to some non-power supply part of the case.
It turns out that for some random reason, the capacitance of some component needing tweaking, and this was done via... magic!
I always thought it would be a great idea for 3-d games to include a l10r lens in the box, for the true 3-d effect. Positioning it on the monitor would be fiddly, but shoudl work ok: many crts give you screen re-sizing controls, and you could use subpixel positioning on LCDs.
I would suggest just interleaving two images -- or at most three. I've written about this before, but can't be bothered to fight with slashsearch to find it.
That's just a boatload of pixles to be pumping down the pipe. I wonder how long it will be until hi-res monitors incorporate some vector rendering hardware internally, in order to assauge the bandwidth problems of dvi.
you probably don't want a full-blown postscript renderer, but something along the ideas of display postscript, or even quickdraw, would probably reduce bandwidth incredibly.
I've often mused about perhaps using proto-mpeg down the display connector as well, as scaling only needs to be done at the very last stage. However, this would be more complicated, as you'd need to be able to download new drivers into the monitor somehow. Perhaps you could write those drivers in postscript... (loop to top of post)
of course, unless you're doing long _really_ data intensive things you don't care about rate , but latency. And latency only improves with RPM, not density. Waiting for the sector to go spin into place is a real killer.
hrm. I'm about 8 years out of the classes where I could have calculated this, but doesn't diffuse reflection (as used in projection) destroy polarization?
I had assumed that these guys used alternating l/r images and synced them up with lcd shutter glasses, but apparently not!
I expect that he merely adds some salt, encrypts that + the one-time-pad in one of the stream modes (CFB?), and uses THAT as the "session OTP" for the message.
Security in this case would be equivalent to the encryption used to generate the session OTP, not the provable security of the a true OTP.
I think schneier was the one to point out that we are all able to invent ciphers that we can't break ourselves. The good ciphers are the ones that can't be broken by others.
You may want to look into flac, which is roughly 50% of raw audio, IIRC.
I ASSUME it is fairly cheap to codec.
If you're into building from components, I'd suggest picking up a pre-hacked i-opener from ebay (expect to pay ~ $70-100 +s/h depending on size of included hd and quality of work).
The midori for iopener image (see google for url) gives you a web browser, xmms, and a linux kernel that can drive: kawasaki/pegasus based usb ethernet; linksys wusb11v2.5 (important about the v number. 2.6 is in stores now, and won't work) 802.11b; usb audio out.
The i-opener comes with an acceptable 800x600 lcd and a crappy ps/2 keyboard+mouse combo.
So you can start cheap and use the built in audio and a netgear ea101 for ~ $100 (NB: the iopener doesn't have audio out, so that has to be hacked in. Trivial hack, but needs to be done if you don't want to use usb audio) and grow it to have wireless network and spdif output for another $100, when you feel you want that.
The only drawback is that I haven't figured out how to turn off the backlight (or more accurately, turn it back on again), but the thing boots to xmms in about a minute, so that's not a killer.
beetles are funny. I still smile at the story (told by gould?) about the zoologist asked what his work could tell us about god (this was in the times when this was conscidered a meaningful question).
his answer: "He must have an inordinate fondness for beetles."
actually an old colleague of mine had the opinion that functional languages weren't _inherently_ more productive, but _did_ tend to attract programmers who understood abstraction at a deep level.
these guys can write good code in _any_ language (he was a scheme hacker who was busy optimising HAIRY C gc code), but are attracted to functional langs because such langs directly capture the abstractions these guys use.
so, to paint with a broad brush, functional languages aren't nec. better than imperative, but the functional paradigm (abstraction, genericity, focussing on data rather than process) IS.
winamp.org, I think. xmms can use winamp skins.
no, the killer is that the kernel headers aren't installed by default --- or maybe not the headers, but whatever the advanced 3rd party kernel modules like gatos and linux-wlan-ng need in order to configure themselves.
I've never needed to recompile the kernel, but I have needed to find and install the kernel sources (for rh 7.2) in order to compile modules.
I found the milk one -- either spiltmilk or bluemilk, forget the exact name -- and have never wanted to change. Fantasically beautiful and usable.
I doubt all the bandwidth wasted on unnecessary disk downloads will be paid for by a higher pctage of people who buy the disks.
So say I'm wrong and you sue me.
fine, I lose, and the court awards you damages.
but you want me to pay your expensive lawyer too!? that should come out of your winnings. Else we are basically giving the lawyer the right to assess damages me as well, but without any legal guidelines as to the ammount.
Seems fairer to me that the suit bringer always pays his lawyer, and also the defendant's, if the suit is overturned.
That way, people only sue if they are sure to win, and rich people or companies can't sue poorer people just to harass them into settling out of court.
And there's no risk in sticking your neck out if you know you are right.
those cooling lasers work like throwing marbles at a bowling ball to control its motion (ie, rather than moving just energy, you need to fiddle with momentum).
The cool bit is that the lasers are tuned so that doppler shift decides whether the atom absorbs a photon (is hit by a marble) or not.
a low level solution is a design _requirement_!? That seems ill-considered.
http://www.phys.uu.nl/~steen/web02/opteron.html
You may want to conscider the meaning of the word "internal". Of course the emulator wouldn't expose the internal instruction set. That's the whole point of an emulator: get the same result by different implementation. The internal risc ops are an implemenation hack. I thought this came through in my post.
my GUESS is that the opteron line has two instruction sets: the normal x86 compatibilty instructions, and the native amd internal 64 bit instructions that the x86s are translated to.
Almost all high performance x86 compatible chips run another instruction set internally, because the x86 is just to damn weird. The translation happens transparently.
However, given that AMD will have put alot of effort into said translation, I don't see that going to plain x86 and thereby being able to reuse all the mature tools for that instruction set as being too stupid a move.
what about devices? Are they virtualised?
No I haven't done any research.
so they'll move to 802.11a when that matures
orbit goes really well with the bumblebee gtk theme
crap! ended up in the wrong thread.
What I wanted to say here was that I'd be _real_ worried if any hard-drive were susceptible to a holistic bracelet's magnets. I mean magnetic fields decay as the square of the distance, and the magnets inside the drive are 1) strong as fuck, and b) _really_ close to the platter.
I seem to recall a story about the MIT AI lab having an old machine with a "magic" switch. The machine _would not run_ wihtout magic turned on.
Ok. cute, you think. Someone has wired the "magic" to control the power supply.... nope.
On opening the case, there is only one (1) conductor going from the switch to some non-power supply part of the case.
It turns out that for some random reason, the capacitance of some component needing tweaking, and this was done via... magic!
I always thought it would be a great idea for 3-d games to include a l10r lens in the box, for the true 3-d effect. Positioning it on the monitor would be fiddly, but shoudl work ok: many crts give you screen re-sizing controls, and you could use subpixel positioning on LCDs.
I would suggest just interleaving two images -- or at most three. I've written about this before, but can't be bothered to fight with slashsearch to find it.
That's just a boatload of pixles to be pumping down the pipe. I wonder how long it will be until hi-res monitors incorporate some vector rendering hardware internally, in order to assauge the bandwidth problems of dvi.
you probably don't want a full-blown postscript renderer, but something along the ideas of display postscript, or even quickdraw, would probably reduce bandwidth incredibly.
I've often mused about perhaps using proto-mpeg down the display connector as well, as scaling only needs to be done at the very last stage. However, this would be more complicated, as you'd need to be able to download new drivers into the monitor somehow. Perhaps you could write those drivers in postscript... (loop to top of post)
A 300 dpi printer cannot make a like 1/300th of an inch wide. However, it _can_ position this too-wide line with 1/300th inch precision.
However, a monitor can do both.
Not that this matters much: you seldomly need feature sizes that small.
of course, unless you're doing long _really_ data intensive things you don't care about rate , but latency. And latency only improves with RPM, not density. Waiting for the sector to go spin into place is a real killer.
Or at least that's what I'd expect
hrm. I'm about 8 years out of the classes where I could have calculated this, but doesn't diffuse reflection (as used in projection) destroy polarization?
I had assumed that these guys used alternating l/r images and synced them up with lcd shutter glasses, but apparently not!