But you forget. Each cone is not a single "pixel" to our retna. It is a sampling point for a complex signal transform. With the right tricks you can fool the eye into "seeing" several times the resolution it thinks it's seeing.
Well according to the doppler effect, yes. The same way a running faucet when you are standing at a sink will drown out somebody yelling to you from upstairs.
The problem isn't how to pipe data directly to the brain. Hell, an electrode will do that just fine. The real technological feat will be delivering a signal to that part of the brain that can actually do something with it.
Until then, we will have to be satisfied with tricking the senses.
As for object files - which word in the phrase "compiles directly to memory" is not clear to you? And do we actually need to store the object files? Couldn't it just be linked on the fly?
No, you can't link on the fly. Linking requires that you have all the object code available for the final product to be able to connect the dots. It's like attaching the hoses and cables of the car before installing the components.
As far as compiling to memory, what part of, 4.8 million lines of code is not registering to you.
In between my last post and this I compiled 2.6.6. The bare source is 233 MB. Compiled, 307Mb. The difference (minus a megabyte or three for the final bzimage and modules) are the object files, dependecy indexes, and other "products" of the compile process. Any RAM based linking would still need to manipulate the same volume of symbols, so you are talking about needing 75 MB just to perform the final link.
And of course the linker will need it's own RAM to work with.
I'm not the first to say this. If encrypyion is the solution to your problem, you either don't understand encryption, or the problem.
No matter how good your cipher is, if it contains computer codes it is decoded into plaintext somewhere in the computer's memory. Someone with access to the right equipment will happily trace what is going on inside and copy out the needed data as it goes streaming out from the decryptor.
As far as on-the-spot compiling, your equipment better have a ton of horsepower. We are talking about churning through, and linking, 4.2+ million lines of code. That's a lot of RAM and CPU time for an embedded device.
Supplying a complete source to your proprietary kernel doesn't sound like a very secure way of achieving your stated goal.
Much simpler to write your kernel into the BIOS, and have each unit posess a custom build incorporating your key checks with hardware locks elsewhere on the system.
Otherwise it would be short work for someone to simply parse through the code and comment out or write around your hooks.
Yes, it's on a filesystem, but if you'd bothered to actually look at the source you would have seen that TCCBOOT includes code to unzip the romfs filesystem and read files from it without any kernel support. And TCC does NOT need to output to a filesystem, it can compile straight to memory and execute the compiled code.
Yes, that covers READING the file, but it doesn't cover how exactly the contents of that file are to be divined from the hardware. It also doesn't cover where the object files for compilation are going to life. Even a ram-disk needs a driver.
2.6.6 is 213MB unpacked. That's just the source, build scripts, and flat-file hardware databases. The compile products (object files) easily blow out to twice that. And the compiler itself consumes a tremendous amount of memory assembling that object files. And then once you have the object files, the linker steps in, which also requires a tremendous amount of memory.
We are talking about consuming 600 MB in just ram disk.
Writing to a disk is a requirement. At least if you want to have any RAM left to boot your OS.
Hmmm, my work laptop has been recently re-formatted to Win2K. I've been noticing boot times of 2 minutes, 3 minutes, EVEN 5 MINUTES OR MORE! Well, at least that's what it's promising if I send a large sum of money to a certain website.
Considering that most sane people use a stock kernel from their distro, this is pointless. For the folks who build their own kernels (self included) this is pointless. Actually it's worse than pointless, it can leave your ass flapping in the wind.
There are so many goofy little things that can go wrong during the build process. How many times have you added a driver to your config file, only to find the build process dies horribly trying to compile it? How many times have you experienced a build that works fine once, then dies, then works again?
And then there is the issue of where exactly you are planning on putting all the object files, index files, temp files, and so on, not to mention the fact that you are relying on this micro-compiler which MAY or MAY NOT work well with future modifications to the code, and may or may not be able to fully exploit your architecture.
Oh, I can think of some novel worms that you could write into this little scheme.
Back in the day you had to trick the kernel into running malware, or gain enough privileges to trick it into loading a module. Now you can write a worm into the Kernel itself!
/There is a particularly nasty chunk of hell waiting for virus writers. I am not one of them.
Ah, then you have committed the usual blunder of assuming that a social life is not mutually exclusive to family, and they persuing both doesn't leave a lot of time for sex.
Well, at least once kids and home repairs come along.
Actually they don't. There is plenty of anti-trust case law to back up SCC as well. If they lost this case, they could have filed any number of other suits based on the anti-tying provisions of the Sherman anti-trust act. (Several states have similar laws.)
Liability for tying under 1 exists where (1) two separate "products" are involved; (2) the defendant affords its customers no choice but to take the tied product in order to obtain the tying product; (3) the arrangement affects a substantial volume of interstate commerce; and (4) the defendant has "market power" in the tying product market.
Jefferson Parish, 466 U.S. at 12-18.
In this case, a proprietary locking chip that was sanctioned by DMCA would constitute market power.
If you are going be sheer number of launches, body count, payload capacity, or cost effectiveness, the Russians have us beat hands down.
Sure we've been to the moon. But we haven't done a damn bit of fundimental research since then. (A lot of improvements to our unmanned rocket technology have been bought/borrowed/stolen from the Russian program.)
Computers cannot make decisions. They can perform computations. They can evaluate formulas. They can even pen new algorythems. But their decision making power ultimately comes down to flipping a coin.
It can be a very heavily weighted coin, but it is a coin nonetheless.
I'm still trying to figure out why the Apollo formula of contractors with Nasa oversight doesn't seem to work anymore.
Then I remember Apollo 1, that killed 3 astronauts, and Apollo 13, that nearly killed 3 more.
To invoke Heinlien, Space is a harsh mistress.
To invoke Sun Tsu, success in defense is not based on the likelyhood of your enemy attacking. It is based on your position being completely unassailable.
Yes, it may be better to aim for the stars and hit the moon, but it's been my long experience that success is all about managing expectations.
Scotty on the enterprise always tells Kirk that a repair is going to take 3 hours and finishes it it 2. Kirk can plan around that. Now if Scott took the same estimates, promised the job would take one hour if everything went well, and delivered in 2 he would be viewed as incompetant.
Generally when you report a fact to the buying public, the expect it to be a done deal. While they aren't surprised when it isn't, they will never believe another thing you tell them.
With a game studio, overpromsing is almost expected. They are small organizations with rampant turnover, and seem to exist for only a few projects at a time.
Intel and Microsoft are billion dollar companies, run by highly experienced executives, marketers, and engineers. They have lifers on staff for corporate memory. Not only should they know better, it's their job to know better.
Then again, both firms seem to insist on being run like a startup.
Indeed, my best intentions have also gotten me in over my head with promises. It's a learning experience. Some of us have the benefit of learning on a small controlled audience.
Slashdot Mirror
The brain is brilliant at filling in gaps.
If they are any good, maybe you won't see them. (Or much else.)
Well according to the doppler effect, yes. The same way a running faucet when you are standing at a sink will drown out somebody yelling to you from upstairs.
Oh. You wanted it to continue to function...
(If you are seriously diving 300', just put the sucker in your dry suit.)
Until then, we will have to be satisfied with tricking the senses.
No, you can't link on the fly. Linking requires that you have all the object code available for the final product to be able to connect the dots. It's like attaching the hoses and cables of the car before installing the components.
As far as compiling to memory, what part of, 4.8 million lines of code is not registering to you.
In between my last post and this I compiled 2.6.6. The bare source is 233 MB. Compiled, 307Mb. The difference (minus a megabyte or three for the final bzimage and modules) are the object files, dependecy indexes, and other "products" of the compile process. Any RAM based linking would still need to manipulate the same volume of symbols, so you are talking about needing 75 MB just to perform the final link.
And of course the linker will need it's own RAM to work with.
No matter how good your cipher is, if it contains computer codes it is decoded into plaintext somewhere in the computer's memory. Someone with access to the right equipment will happily trace what is going on inside and copy out the needed data as it goes streaming out from the decryptor.
As far as on-the-spot compiling, your equipment better have a ton of horsepower. We are talking about churning through, and linking, 4.2+ million lines of code. That's a lot of RAM and CPU time for an embedded device.
Much simpler to write your kernel into the BIOS, and have each unit posess a custom build incorporating your key checks with hardware locks elsewhere on the system.
Otherwise it would be short work for someone to simply parse through the code and comment out or write around your hooks.
Yes, that covers READING the file, but it doesn't cover how exactly the contents of that file are to be divined from the hardware. It also doesn't cover where the object files for compilation are going to life. Even a ram-disk needs a driver.
2.6.6 is 213MB unpacked. That's just the source, build scripts, and flat-file hardware databases. The compile products (object files) easily blow out to twice that. And the compiler itself consumes a tremendous amount of memory assembling that object files. And then once you have the object files, the linker steps in, which also requires a tremendous amount of memory.
We are talking about consuming 600 MB in just ram disk.
Writing to a disk is a requirement. At least if you want to have any RAM left to boot your OS.
Hmmm, my work laptop has been recently re-formatted to Win2K. I've been noticing boot times of 2 minutes, 3 minutes, EVEN 5 MINUTES OR MORE! Well, at least that's what it's promising if I send a large sum of money to a certain website.
Considering that most sane people use a stock kernel from their distro, this is pointless. For the folks who build their own kernels (self included) this is pointless. Actually it's worse than pointless, it can leave your ass flapping in the wind.
There are so many goofy little things that can go wrong during the build process. How many times have you added a driver to your config file, only to find the build process dies horribly trying to compile it? How many times have you experienced a build that works fine once, then dies, then works again?
And then there is the issue of where exactly you are planning on putting all the object files, index files, temp files, and so on, not to mention the fact that you are relying on this micro-compiler which MAY or MAY NOT work well with future modifications to the code, and may or may not be able to fully exploit your architecture.
This is definitely a nerd mountain.
Back in the day you had to trick the kernel into running malware, or gain enough privileges to trick it into loading a module. Now you can write a worm into the Kernel itself!
Well, at least once kids and home repairs come along.
Liability for tying under 1 exists where (1) two separate "products" are involved; (2) the defendant affords its customers no choice but to take the tied product in order to obtain the tying product; (3) the arrangement affects a substantial volume of interstate commerce; and (4) the defendant has "market power" in the tying product market.
Jefferson Parish, 466 U.S. at 12-18.
In this case, a proprietary locking chip that was sanctioned by DMCA would constitute market power.
No he's just describing his new policies. About how the US needs more "Living Space", and that we need a "Final Solution" to end terrorism.
Onward to Wayland-Yuatani
Sure we've been to the moon. But we haven't done a damn bit of fundimental research since then. (A lot of improvements to our unmanned rocket technology have been bought/borrowed/stolen from the Russian program.)
If a business manager fails, he gets fired. If an engineer fails, a few thousand people could die or be horribly injured.
It can be a very heavily weighted coin, but it is a coin nonetheless.
Then I remember Apollo 1, that killed 3 astronauts, and Apollo 13, that nearly killed 3 more.
To invoke Heinlien, Space is a harsh mistress.
To invoke Sun Tsu, success in defense is not based on the likelyhood of your enemy attacking. It is based on your position being completely unassailable.
Scotty on the enterprise always tells Kirk that a repair is going to take 3 hours and finishes it it 2. Kirk can plan around that. Now if Scott took the same estimates, promised the job would take one hour if everything went well, and delivered in 2 he would be viewed as incompetant.
Generally when you report a fact to the buying public, the expect it to be a done deal. While they aren't surprised when it isn't, they will never believe another thing you tell them.
Intel and Microsoft are billion dollar companies, run by highly experienced executives, marketers, and engineers. They have lifers on staff for corporate memory. Not only should they know better, it's their job to know better.
Then again, both firms seem to insist on being run like a startup.
I personally try to get out of the respawn area as quickly as possible. Damn campers.
Indeed, my best intentions have also gotten me in over my head with promises. It's a learning experience. Some of us have the benefit of learning on a small controlled audience.