So what are some of the other paradigms which might be proferred instead of von Neumann?
My take is that for as long as CPU design is instruction-oriented instead of time-oriented, we won't be able to have truly trusty 'self-repairable' computing.
Give every single datatype in the system its own tightly-coupled timestamp as part of its inherent existence, and then we might be getting somewhere... the biggest problems with existing architectures for self-repair are in the area of keeping track of one thing: time.
Make time a fundamental to the system, not just an abstract datatype among all other datatypes, and we might see some interesting changes...
Its a pity they don't get the point that there's a market, then, for devices with loadable batteries... Their diy approach (they do do batteries too, right?) cripples them all the way to the end.
Still, I dig the NX70V highly. Be good to at least have CF and W-lan one day... At that point, who cares about TV?
Oh yeah, hah hah, right. The system is broken so just pile on even more crap to fix it (MFC).
Go ahead, flounder in your nonsensical API goodness! Revel in 3rd-party hacks to shitty OS design! Bask in the glory that is MFC42.dll! Roll in the ecstascy of monthly MSDN update CD's!
Sheesh. I dunno, seems to me like the 'new generation' of computer nerds just don't get it... If you can't guess half the API after having read 10% of it, then it's NOT A GOOD DESIGN!
Heh heh... so, hey... what is "Adult Swim" all about?
Frankly, if I can get my fix of Simpsons (even though its dubbed in German... *shudder*...) from the local TV station using just my Clie NX70v and this little doo-hickey, then I guess my life will be complete.
Ummm... if someone doesn't like our content, its only because they *SUBSCRIBED themselves* to the box, and even then they've got a choice: unsubscribe, and never hear from the ampfea.org community again.
The problem here is SPAM: un-requested, un-related, non-sequitur e-mail being sent to thousands of people indiscriminately.
*WE DO* discriminate between those that want to be involved and those that don't. So, we've got to be taxed as a solution to the problem created by those who do not discriminate?
As for your "who will be left..." point... well, lets just say that if communication is taxed, there won't be anyone left to say much at all about anything any more.
Sure... lets see... theres ummm... LoadLibrary(), then there's LoadLibraryEx(), then there's LoadLibrary32(), then there's LoadLibrary32Ex(), then theres MS_LoadLibrary(), then theres MS_LoadLibrary32(), then theres MS_LoadLibraryEx()...
Oh, okay, I give up. I only ever used LoadLibrary() a couple hundred times, personally, and even then, only to get incompatible API functions loaded from various copies of the same.DLL found all over C:\WINDOWS, C:\WINDOWS\SYSTEM, C:\WINDOWS\SYSTEM32, C:\WINDOWS\WINNT, etc.
I dl'ed and played ThinkTanks (for OSX, yay!) today and found it to be totally fun... not exactly huuuge in terms of investment, but very fun to play. I'm especially happy that there are game companies like GarageGames out there who are willing to do Linux/Win/OSX releases all together, and their Torque Game engine SDK seems fit for this scenario...
I think we could look forward to more interesting, fun games from the Torque engine in the future. Cross-platform too, woohoo!
That means there will be 68,000 'hidden' API functions to discover later on down the line when we find out that Microsoft are still using them themselves... 'internally'!
"Microsoft cleans up its API". I never thought I'd see the day when this was actually news... but it makes you wonder why its so exciting, eh? Short answer: Because EVERY API ever released from Redmond has SUCKED ASS.
I'm *ALREADY* paying for my bandwidth usage and we own the box we run on, thanks to donations made by our existing contributing members.
Add to that yet *another* bill in the form of a tax for each email message? No way, no thanks. We'll just move our box somewhere more friendly to a democratic, free way of thinking, and avoid all police states entirely...
I run ampfea.org. We have been an open, free, highly communicative community for the last 6 years, surviving solely on contributions (donations) made by members to keep our services alive. We've done okay with it, but it hasn't been easy at times.
Now, adding *tax* to our e-mail (most of our forums are based on mailing list traffic) would completely cut down on the ability for members to communicate freely. Tax on e-mail is a *BAD* idea.
There are plenty of effective ways to deal with the SPAM problem. Tax is not one of them. Tax is never a solution to any problem.
I tend to think it is a 'handheld' killer in the sense that modern handhelds are monolithic in design - all in one.
This device breaks the rules requiring such a design sense, particularly if it uses smart software in the controller to make connection to other devices seamless and painless to the user.
Solve all the problems of negotiation and networking at the *SERVER* level (i.e. the disk), and suddenly the world opens up if you take out the disk and put in... say... CPU's (or DSP's).
From that point on, how much computing power you've got available depends on how much everyone else on the train has decided to commit to the public 'processing power' pool... or, hey, far out there... how much DSP power you've got to render your concert with depends on just how much your fans have given you... and from the flipside, if it was a good gig you can just stream the edits of it straight to the "Personal Servers" of whoever was there, just for posterity (and price of admission).
Ummm... think about this a little more, and you might see that the use of the term 'handheld killer' is appropriate.
All other handhelds on the market today have the same limitations: RAM size, battery life, disk space.
This box eliminates that problem, and in fact it propels things *far* into the future, past this point. Should this product become ubiquitous, then this is the point:
- Handhelds need only be screen, battery, WiFi.
What OS you use as an 'interface' becomes irrelevant. Hell, bundle an embedded JAVA or Flash player in the screen controller, and all those fears which Microsoft had about becoming irrelevant in the face of the browser come to fruition... albeit, on an entirely new computing platform where the *communication protocols* set the standard, and all else (CPU type, speed, casemod) becomes irrelevant.
The point is, this "server" really *IS* personal computing, to the next level.
Take out the disk, and throw in some CPU's... or (*shudder*) some DSP's, add some smart code at the WiFi/Bluetooth layer, and you've got an amazing new computing system.
Let's look at some other applications for this product, shall we? Say these prototypes from Intel become more popular, and hit the shelves...
So, you're at a concert and you're really enjoying it. You swipe your credit card through the reader at the door on the way out, and by the time you've walked to your car in the parking lot, you've got the live concert mix in your pocket.
From my perspective (I work for Access), I can see a hell of a lot of good uses for this prototype for Intel.
How do you - at a consumer'ish level - fix the ugliness of the IDE cable, and non-hotswappable capabilities? I would think being able to load disks on and off without having to do a full system re-boot would be pretty advantageous... more important than speed concerns, anyway.
Can your PC really do sustained writes to >8 drives without getting into performance issues?
Actually, speed is a good point. I guess I hadn't thought about that so much as part of the setup, but I guess if you're exercising disks to make them fail, you want to do it as fast as possible... even though, in your end-system where the disks will be used, a Firewire stress-test may be more realistic in terms of disk behaviour.
It's kinda stupid to only do *8* disks at a time, when you can easily do 64... using Firewire.
My advice would be to investigate into as many Firewire->IDE convertors as your company can afford, and then use a Firewire-friendly OS to do the burn-in. Something like OSX or Linux would work very well in this case - actually, a cheap Apple machine would be perfect for this application.
There's no need to start things up in batches with Firewire, either. You can plug in a disk, and your 'stresser' program can be written in a way that it just picks up that disk, stresses it, and reports failures along the way.
Would be a very simple project. If you want specific help, feel free to contact me...
Slashdot Mirror
So what are some of the other paradigms which might be proferred instead of von Neumann?
... the biggest problems with existing architectures for self-repair are in the area of keeping track of one thing: time.
My take is that for as long as CPU design is instruction-oriented instead of time-oriented, we won't be able to have truly trusty 'self-repairable' computing.
Give every single datatype in the system its own tightly-coupled timestamp as part of its inherent existence, and then we might be getting somewhere
Make time a fundamental to the system, not just an abstract datatype among all other datatypes, and we might see some interesting changes...
... drats, got Apple on my mind today ...
Its either a) running FreeDOS+KarlBridge, or b) running KalrBridge under some other layer.
Karl did the development for the original iPod, I'd be surprised if they aren't also the ones behind the AP Extreme.
Details Here...
Oh, well then, you're a bit (2 years) older than me, so ... umm ... sorry there grandpa.
Yeah, I (quite fondly) remember the days when Microsoft only shipped a BASIC interpreter, and thats it.
Which is why I find their current scenario so laughable!! HAH HAH Microsoft!!!
C'mon, you gotta take a pic.
I'm off to google. Thanks very much.
Its a pity they don't get the point that there's a market, then, for devices with loadable batteries... Their diy approach (they do do batteries too, right?) cripples them all the way to the end.
Still, I dig the NX70V highly. Be good to at least have CF and W-lan one day... At that point, who cares about TV?
... becomes 'wish' ... ta-dah! ... observable phenomenon, becomes empirical, done.
Or what?
Stanislaw Lew.
Piss. Take.
Oh yeah, hah hah, right. The system is broken so just pile on even more crap to fix it (MFC).
... If you can't guess half the API after having read 10% of it, then it's NOT A GOOD DESIGN!
Go ahead, flounder in your nonsensical API goodness! Revel in 3rd-party hacks to shitty OS design! Bask in the glory that is MFC42.dll! Roll in the ecstascy of monthly MSDN update CD's!
Sheesh. I dunno, seems to me like the 'new generation' of computer nerds just don't get it
Heh heh ... so, hey ... what is "Adult Swim" all about?
... *shudder* ...) from the local TV station using just my Clie NX70v and this little doo-hickey, then I guess my life will be complete.
Frankly, if I can get my fix of Simpsons (even though its dubbed in German
Utterly.
Ummm... if someone doesn't like our content, its only because they *SUBSCRIBED themselves* to the box, and even then they've got a choice: unsubscribe, and never hear from the ampfea.org community again.
... well, lets just say that if communication is taxed, there won't be anyone left to say much at all about anything any more.
The problem here is SPAM: un-requested, un-related, non-sequitur e-mail being sent to thousands of people indiscriminately.
*WE DO* discriminate between those that want to be involved and those that don't. So, we've got to be taxed as a solution to the problem created by those who do not discriminate?
As for your "who will be left..." point
Thank you, Spam GODS!!!
Sure ... lets see ... theres ummm ... LoadLibrary(), then there's LoadLibraryEx(), then there's LoadLibrary32(), then there's LoadLibrary32Ex(), then theres MS_LoadLibrary(), then theres MS_LoadLibrary32(), then theres MS_LoadLibraryEx() ...
.DLL found all over C:\WINDOWS, C:\WINDOWS\SYSTEM, C:\WINDOWS\SYSTEM32, C:\WINDOWS\WINNT, etc.
Oh, okay, I give up. I only ever used LoadLibrary() a couple hundred times, personally, and even then, only to get incompatible API functions loaded from various copies of the same
... is the fact that the engine for this game (and 4 others) is also available, is cross-platform, and is easy to use.
Check here for details.
I dl'ed and played ThinkTanks (for OSX, yay!) today and found it to be totally fun... not exactly huuuge in terms of investment, but very fun to play. I'm especially happy that there are game companies like GarageGames out there who are willing to do Linux/Win/OSX releases all together, and their Torque Game engine SDK seems fit for this scenario...
I think we could look forward to more interesting, fun games from the Torque engine in the future. Cross-platform too, woohoo!
That means there will be 68,000 'hidden' API functions to discover later on down the line when we find out that Microsoft are still using them themselves
"Microsoft cleans up its API". I never thought I'd see the day when this was actually news
I'm *ALREADY* paying for my bandwidth usage and we own the box we run on, thanks to donations made by our existing contributing members.
...
Add to that yet *another* bill in the form of a tax for each email message? No way, no thanks. We'll just move our box somewhere more friendly to a democratic, free way of thinking, and avoid all police states entirely
"Phase Vocoder is 2nd generation"?
Boy, it sure sounds like you know what you're talking about here, but I'll bite.
What is meant by a "2nd generation phase vocoder", please?
I run ampfea.org. We have been an open, free, highly communicative community for the last 6 years, surviving solely on contributions (donations) made by members to keep our services alive. We've done okay with it, but it hasn't been easy at times.
Now, adding *tax* to our e-mail (most of our forums are based on mailing list traffic) would completely cut down on the ability for members to communicate freely. Tax on e-mail is a *BAD* idea.
There are plenty of effective ways to deal with the SPAM problem. Tax is not one of them. Tax is never a solution to any problem.
I tend to think it is a 'handheld' killer in the sense that modern handhelds are monolithic in design - all in one.
... say ... CPU's (or DSP's).
... or, hey, far out there ... how much DSP power you've got to render your concert with depends on just how much your fans have given you ... and from the flipside, if it was a good gig you can just stream the edits of it straight to the "Personal Servers" of whoever was there, just for posterity (and price of admission).
This device breaks the rules requiring such a design sense, particularly if it uses smart software in the controller to make connection to other devices seamless and painless to the user.
Solve all the problems of negotiation and networking at the *SERVER* level (i.e. the disk), and suddenly the world opens up if you take out the disk and put in
From that point on, how much computing power you've got available depends on how much everyone else on the train has decided to commit to the public 'processing power' pool
Ummm... think about this a little more, and you might see that the use of the term 'handheld killer' is appropriate.
... or (*shudder*) some DSP's, add some smart code at the WiFi/Bluetooth layer, and you've got an amazing new computing system.
...
All other handhelds on the market today have the same limitations: RAM size, battery life, disk space.
This box eliminates that problem, and in fact it propels things *far* into the future, past this point. Should this product become ubiquitous, then this is the point:
- Handhelds need only be screen, battery, WiFi.
What OS you use as an 'interface' becomes irrelevant. Hell, bundle an embedded JAVA or Flash player in the screen controller, and all those fears which Microsoft had about becoming irrelevant in the face of the browser come to fruition... albeit, on an entirely new computing platform where the *communication protocols* set the standard, and all else (CPU type, speed, casemod) becomes irrelevant.
The point is, this "server" really *IS* personal computing, to the next level.
Take out the disk, and throw in some CPU's
Let's look at some other applications for this product, shall we? Say these prototypes from Intel become more popular, and hit the shelves
So, you're at a concert and you're really enjoying it. You swipe your credit card through the reader at the door on the way out, and by the time you've walked to your car in the parking lot, you've got the live concert mix in your pocket.
From my perspective (I work for Access), I can see a hell of a lot of good uses for this prototype for Intel.
I hope it hits.
Well, what should Mr.Gibsons favourite sites be then, smarty?
That's surely not a terribly difficult program to write.
Apple doing it costs them *very* little, and increases the market for their iPods.
I forget, how did it end?
How do you - at a consumer'ish level - fix the ugliness of the IDE cable, and non-hotswappable capabilities? I would think being able to load disks on and off without having to do a full system re-boot would be pretty advantageous... more important than speed concerns, anyway.
Can your PC really do sustained writes to >8 drives without getting into performance issues?
Actually, speed is a good point. I guess I hadn't thought about that so much as part of the setup, but I guess if you're exercising disks to make them fail, you want to do it as fast as possible... even though, in your end-system where the disks will be used, a Firewire stress-test may be more realistic in terms of disk behaviour.
Either way, there's tradeoffs.
It's kinda stupid to only do *8* disks at a time, when you can easily do 64 ... using Firewire.
...
My advice would be to investigate into as many Firewire->IDE convertors as your company can afford, and then use a Firewire-friendly OS to do the burn-in. Something like OSX or Linux would work very well in this case - actually, a cheap Apple machine would be perfect for this application.
There's no need to start things up in batches with Firewire, either. You can plug in a disk, and your 'stresser' program can be written in a way that it just picks up that disk, stresses it, and reports failures along the way.
Would be a very simple project. If you want specific help, feel free to contact me