Slashdot Mirror
The Disposable Computer
sp00 writes "A disposable paperboard computer has been developed and is already in use in Sweden. Developed by Cypak AB, the paperboard computer can collect, process, and exchange several pages of encrypted data, the company says." Pretty impressive, given that they say it has a mere 32K of memory.
I remember when a 32K Commodore PET was a cool thing. ... Just imagine a cluster .... in a three ring binder.
If they print double sided could they emulate a Commodore 64.
In a few more years
134340: I am not a number. I am a free planet!
So what's the payout for collecting pounds of these and returning them to my local recycling center?
The difference between disposable and classic is age. My three year old PC is disposable. My 15 year old PC is a classic and goes for $9,000 on Ebay.
The only thing necessary for Micro$oft to triumph is for a few good programmers to do nothing". North County Computers
Somebody help me: I keep my todo/dates, todo/tasks, books/want, books/have, tidbits in a plain Unix text file and I maintain it with a text editor and print it using a2ps -2. My life fits in two columns landscape mode.
Whenever I need it, I print it, at a cost of 17 cents on my inkjet. When I need to update it, I simply use a pen and "sync" at home later.
I can fold it, put it in my pocket, access the data randomly instantly, and easily add graphics or test with a 0% error rate. However it gets expensive at 17 cents per sync.
All I need is a little bit of memory (32k) and a read-only display screen, super-tiny, and cheap as hell. If America wasn't ass-backwards, I'd just SMS the stuff to my cell phone.
As an employee at Microsoft I had TWO of the top of the line PocketPCs : I played quake on them, wrote some C programs, and put them away as toys. I need to do WORK, as a technical person, not a salesman. All I need is digital paper.
What can I use?
Cypak says the card's encryption can't be copied or broken, enabling it to deliver "military-class security."
sigh.
Belief is the currency of delusion.
Why climb everest?
I think you'll find the answer to both questions is "why not?"
Not so. The true answer to all questions is: "to improve my chances of getting laid".
-kgj
-kgj
Noop! It has to do with code reuse. The code just gets more genral and bigger. But it also gets easyer to develop.
So we get big and slow quick and cheep.
(quick = less hours)
(less hours = cheeper)
CIA Factbook 2002 (US):"Since 1975, practically all the gains in household income have gone to the top 20% of households
Yes, it certainly was. The Mac was not Apple's first computer with a mouse and a graphical interface. That was the Lisa, which nobody bought, because it was too expensive. A colour Mac would have required a huge frame buffer in order to provide adequate resolution. The memory costs of this would have pushed the price too high. Also, the 7MHz CPU was not fast enough to draw text and windows on a colour graphics display (again, unless the resolution was too small to be useful).
And keep in mind that the Lisa, despite its immense cost, was also black and white. So was the Xerox Star (another failed GUI computer that cost too much).
The Mac was not the first personal computer with a GUI. It was the first GUI computer that was cheap enough for ordinary people to buy. The hardware limitations you mention were necessary to keep the cost down.
Doug Moen
I have written a truly remarkable program which this sig is too small to contain.
Many "calculators" today run general purpose processors and can be used for general purpose computing. I believe my old 1991 TI-82 has a Z80 in it.
It seems to me this new device has some ideas in mind for it should be used for, but is fairly general purpose. At the moment, its a computer. Though the systems it becomes embedded in might be called something else.
Just like my calculator's processor could be used in a 'computer'. But its embedded use is for arithmetic and algebra, therefore its a 'calculator'
-
It is certainly true that a bad algorithm can result in slow code, but most of the difficult performance problems I've had to tackle in the last several years are more closely related with bloat. In other words: virtual memory thrashing.
Data structures are often suspect when thrashing is a problem. If nodes are scattered far and wide, then the page file can get a workout. Powerful, dynamic containers often have high-overhead per node and make little if any effort to improve locality of references. More than once I've had to replace an STL map with a hash table in order to get decent performance. (I don't intend that as a blanket condemnation of STL, it's probably just a funky implementation.)
But it's not just data structures. Code bloat in general increases working sets. The structure of code, with long chains of hooks in message passing and method invocation, can result in skipping through dozens of pages.
When programs were simpler, smaller and more procedural, performance problems appeared inside loops. Number crunching is still this way.
But today we have interactive, event-driven programs implemented with deep object hierarchies that mask how much code is actually being called. A single button click to bring up a dialog can trigger tens of thousands of lines of code scattered all across virtual memory. Branch prediction doesn't help here. Level 1 caches don't help. Pipelines are stalled. The processor waits for the VM manager to deliver the next instruction to RAM. With hardly a loop in sight.
We have few tools to fight this type of performance problem. You can get more RAM or use less memory. You can try to improve the locality of your data structures and your code, but those efforts are often at odds with a lot of modern practices such as object-orientation, enhancement by derivation, and letting the VM manager and the garbage collector worry about it.
Hardware has gotten inconceivably faster, but software has hardly picked up the pace (in most domains). Sure, the code does more today, but the factors still don't add up. And it can't totally be explained by a bunch of bad algorithm choices. Code bloat is a big problem.
Fight code bloat.