A decision machine is going to behave like a Turing machine.
Period.
Analyzing where and how decisions are made is useful. Getting rid of the decision step itself is not.
Turing is not the problem.
The problem is the real world, and the fact that models are never the real thing, or there would be no reason to build models.
Inventing a new programing model that somehow avoids the Turing bottleneck (instead of postponing it or spreading it out) could solve the problem if you could solve the problem of solving problems without solving them.
The only way to escape entropy is to leave the mortal world.
QED, and if you don't understand why, well, anyway, the Turing model itself is not the problem.
If our wheels are triangular and Microsoft keeps selling us on the idea that wheels are supposed to be triangular, then we need more people to tell it like it is.
Won't argue with the idea that the x86 and ARM architectures offer a execution models that can be separated from the iron more effectively than, say, the power PC.
But if we can get beyond that point, the x86 model is just plain wrong. Screwball, really. And it gets in the way when you want a different execution model.
If you want a really good, high-level model, the FORTH processor is much closer to an optimal general-purpose execution and computation model. It's missing a few points, too, but it's probably the most optimal real silicon we have, even if Chuck can't afford to build them in the GHz clock range.
The x86 model is effective to the degree it can emulate the FORTH processor model. But it just screws the model up in certain places.
Slashdot Mirror
if you put a lock on a box and leave the box in the middle of the highway, is the box secure?
I'm inclined less to access control lists (vectors, whatever) and more to ephemeral users (kind of like sandboxes for everything, but not really).
The other things are at least a little bit easier to deal with when the underlying execution model is stable.
Bill Gates and Steve Ballmer made the mess, and I'm doing my best not to sit in it.
You keep harping about the turing model.
What do you suggest to replace it? Magic?
A decision machine is going to behave like a Turing machine.
Period.
Analyzing where and how decisions are made is useful. Getting rid of the decision step itself is not.
Turing is not the problem.
The problem is the real world, and the fact that models are never the real thing, or there would be no reason to build models.
Inventing a new programing model that somehow avoids the Turing bottleneck (instead of postponing it or spreading it out) could solve the problem if you could solve the problem of solving problems without solving them.
The only way to escape entropy is to leave the mortal world.
QED, and if you don't understand why, well, anyway, the Turing model itself is not the problem.
Bosses keep saying, why re-invent the wheel?
If our wheels are triangular and Microsoft keeps selling us on the idea that wheels are supposed to be triangular, then we need more people to tell it like it is.
So, your suggestion is to get rid of CPUs?
Should I translate that to, let's convert all of our software to run on dedicated finite-state machines? One machine per program?
You mean the race condition between the marketing department's release schedule and the engineering department's bugzilla?
The most correct program in existence consists of exactly one instruction:
NO-OP
and it is unfortunately not correct in all contexts.
I'm wondering how the license issues will fall out on locked-down Android based devices, and that is part of the problem.
(Locked-down and tied-down are slightly different things.)
nt;
semi-intelleigent sounding stuff that presumes INTEL has already won.
Shoot. Why not just give in to the BORG entirely?
I don't get why there are people here who still don't get this.
If it's a bottleneck on Puppy or basic Debian, it's going to be a bottleneck on MSWinxxx.
The RAM is not the problem. The problem is the wetware of engineers who deliberately throw up roadblocks to using a decent OS.
Hmm. Replying to myself, I see I may have spoken a little too hastily:
http://www.netbsd.org/ports/#ports-by-cpu
http://www.openbsd.org/armish.html
Or OpenBSD.
Plenty useable.
ergo, source code
The point is that some of us find we didn't want to type what the input method predicts.
Yeah, and it tends to predict all sorts of things I didn't want to write.
Seems to work fine for the jr. high school kids, however.
I've noticed that many of my Japanese friends do not consider the keyboard at all convenient, by the way.
Won't argue with the idea that the x86 and ARM architectures offer a execution models that can be separated from the iron more effectively than, say, the power PC.
But if we can get beyond that point, the x86 model is just plain wrong. Screwball, really. And it gets in the way when you want a different execution model.
If you want a really good, high-level model, the FORTH processor is much closer to an optimal general-purpose execution and computation model. It's missing a few points, too, but it's probably the most optimal real silicon we have, even if Chuck can't afford to build them in the GHz clock range.
The x86 model is effective to the degree it can emulate the FORTH processor model. But it just screws the model up in certain places.
I'd personally prefer to get my employees home to their families.
Corn, perhaps, can be grown by machine.
Who's going to wrastle the beef?
And who's going to sweat over the grill?
Only if the class material is accurate.
WoW is not reality, and too much of the business simulation stuff is not reality either.
Dang, where have I seen that before?
I guess it's a less revolting fantasy than others that have been picked up here.
Just being a bother isn't enough to figure out the difference between a provider and a search engine.
"And the man comes on to tell me, how bright my teeth should be."
Or is it, "My clothes are 100% whiter with Bing (TM) brand Detergent?"
testimonials, testimonials let's have more testimonials.