You neglect emulation overhead - for each instruction in the emulated box you're probably executing a few dozen instructions of the host processor, probably with a computed jump to mess up pipelining too. Since the XBox uses an x86 processor, it can be emulated without this overhead (e.g. with a modded version of vmware)
Linux uses EXT2, ReiserFS, XFS, or one of a few others usually, but on a camera you don't need a sophisticated fs like those (and probably don't have the CPU/RAM either). MinixFS would probably be ideal.
Good luck running a SQL RDBMS on a digital camera. A Microsoft RDBMS, at that. You'll need a Pentium chip and 64 MB of normal (not picture storage) RAM just for the OS to run all this cruft.
From what I understand, umsdos (support for unix semantics on dos filesystems) just hasn't been rewritten for the new kernel APIs yet, but will be in the future.
__asmlinkage inline unsigned int add_x_plus_y(unsigned int x, unsigned int y){
unsigned int ret;
spin_lock_irq(¤t->arith->lock);
current->arith->accum = x;
current->arith->oprand = y;
__perform_add(¤t->arith);
ret = current->arith->accum;
spin_unlock_irq(¤t->arith->lock);
return ret; }
Re:The "security blanket" factor
on
Javascrypt
·
· Score: 1
The algorithm Javascrypt implements is absolutely useless for what you're talking about. AES is a symmetric encryption algorithm, which means that if you're going to send the data to some server using Javascrypt, at some point you need to communicate the key. If you send the key with the data (not to mention the.js for decryption), you've just royally wasted your time. This could only be useful if you agree to a key in advance using some non-internet connection method, in which case you're not going to go with a "cheap ass" encyption technique like this.
Ever hear of Diffie-Hellman? Sure, there's a risk of a man-in-the-middle attack, but it's better than nothing, and will protect against passive sniffing attacks.
Is this implemented in kernel space still? Is it possible to implement a driver wrapper like this in Ring 3, or at least in Ring 1 or 2, thus reducing the effects of a driver crash, instead of Ring 0?
Slashdot Mirror
On the contrary - what about all those companies using SSL? The problem is with breakable encryption, which all DRM is.
The PGP signature can be used to verify that the file's genuine.
No problem.
You neglect emulation overhead - for each instruction in the emulated box you're probably executing a few dozen instructions of the host processor, probably with a computed jump to mess up pipelining too. Since the XBox uses an x86 processor, it can be emulated without this overhead (e.g. with a modded version of vmware)
If you've been using your console for 10 hours, perhaps you have larger problems?
Technically speaking, no computer is turing-complete, as they lack an infinity memory.
Nitpick: They would have to use ALSA (or OSS), as that's the only way to get the sound to the sound card.
What about tuning in software? E.g., GNU radio
I don't know - it seems to be working, so that's unlikely.
What about giFT-fasttrack?
Linux uses EXT2, ReiserFS, XFS, or one of a few others usually, but on a camera you don't need a sophisticated fs like those (and probably don't have the CPU/RAM either). MinixFS would probably be ideal.
Good luck running a SQL RDBMS on a digital camera. A Microsoft RDBMS, at that. You'll need a Pentium chip and 64 MB of normal (not picture storage) RAM just for the OS to run all this cruft.
What's wrong with it?
From what I understand, umsdos (support for unix semantics on dos filesystems) just hasn't been rewritten for the new kernel APIs yet, but will be in the future.
Well, that's okay, as long as we still have a recursive acronym: WINE Is Now an Emulator.
Try using a serial console - you'll probably be able to get a backtrace if/when it OOPSes, or at lease a panic.
Don't be silly, kernel code would be:
#include <linux/config.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/types.h>
MODULE_LICENCE("GPL");
__asmlinkage inline unsigned int add_x_plus_y(unsigned int x, unsigned int y){
unsigned int ret;
spin_lock_irq(¤t->arith->lock);
current->arith->accum = x;
current->arith->oprand = y;
__perform_add(¤t->arith);
ret = current->arith->accum;
spin_unlock_irq(¤t->arith->lock);
return ret;
}
Ever hear of Diffie-Hellman? Sure, there's a risk of a man-in-the-middle attack, but it's better than nothing, and will protect against passive sniffing attacks.
Does this mean SSL over WiFi is illegal?
Well, if you want spinlocks bogging down your uniprocessor kernel go right ahead, but I'd prefer not to.
I don't see why it can't go through e.g. mapping memory and using real-time signals or reading from a device file to receive interrupts...
Is this implemented in kernel space still? Is it possible to implement a driver wrapper like this in Ring 3, or at least in Ring 1 or 2, thus reducing the effects of a driver crash, instead of Ring 0?
Make a Gentoo ebuild script - often trivially done by copying a file for an older one - and put it in /usr/local/portage.