We've got a 10MB limit on attachments at our corporation, which seldom is the real hassle -- it's the 50MB TOTAL e-mail space on the server. So if you get several big attachments over the weekend, and you haven't emptied the Recycle and Sent folders lately, you may find that you can't reply to messages until you clean out some of the trash.
It gets worse -- at 100MB, you can not receive mail at all. Many has been the time I've wanted to send 100 1MB files to the twelfth bozo who forgot not to "Reply to All" when telling some other bozo not to "Reply to All" on a mass mailing.
I know that I'm ignoring the rest of the post... but really. A whole penny per CPU second? $864 per day per processor? Come on, at least attempt to be realistic here.
Urk -- time for me to go back to micro(processor) economics class again.
But let's see what happens when supply and demand can actually be measured. We may see processor prices go up when the value is higher.
Truly, we probably need to price it in gigaflops or something like that. Just figuring the amortization of your PC over three years, an average CPU chip price on a higher-end (2+GHz P4) machine being $300 (generous, maybe counting some of the RAM and mobo cost), divided by seconds per year... about $0.000003 per CPU second. I'll leave the calculation of price per billion floating point operations to somebody with a P4 spec manual handy.
With the millions of PCs sitting around with "Idle" as the busiest process, imagine getting a penny or so per CPU second, selling CPU time on the open market to the
Oil/mineral prospectors who need to process geo data
The national weather service predicting hurricanes
Your local genome sequencer
Now, you have a value for CPU time on the open market. You should be able to
Get a tax deduction for cycles given to SETI, cancer foundations, etc.
Have a value to sue for the loss when you're DOS-ed
Certainly there are other lessons to be learned. IMHO, the biggest bubble-blower is the IPO: in one day, a company's stock could increase in value 20 times. Sure it'd deflate the next week, but the rush of investors brought up the cost of every associated stock.
Amazon and Yahoo bought a lot of startups with that cash, other companies execs I'm sure sold out on their newfound paper wealth, while the average customer asked why he couldn't buy at the IPO price.
Who's at fault there? The analysts who priced the stock so low to begin with? Probably not, when the long-term outlook isn't that far from their predictions. The SEC? Maybe a little bit, but Adam Smith is spinning in his grave over the thought that we should hold back the invisible hand.
In the late '80s, there was a sweet Forth implementation for the Mac called Mach 2. It produced native 68000 code -- unusual because most Forths produced an interpreted byte-code, but possible because of the 68000's stack orientation -- and was cheap (about $50).
While it wasn't the easiest thing in the world to use for building complete GUI apps, it was a great experimental tool because it was essentially an interpreted assembler/disassembler! You could experiment with OS traps that were recently published but hadn't made it to other compiler implementations, and see what machine opcodes would do the job minimally.
You could then take those opcodes and drop them into, say Turbo Pascal (which was barely supported by Borland) as inline machine instructions. Way cool.
The other place where Forth came in handy was a couple several years later when learning PostScript: as a stack-based language, PostScript was a cinch to pick up. Of course, if you've been using RPN calculators, it shouldn't be too bad either.
Forth may be a little low-level in these days when Perl and Python provide such abstract data types, but it makes you think closer to the hardware. When hardware control is an issue (in devices like telescopes, barcode readers, etc.), Forth beats programming in assembler by a long shot.
Slashdot Mirror
Can't.... Read....
Sinuses... filled... with Legalese...
We've got a 10MB limit on attachments at our corporation, which seldom is the real hassle -- it's the 50MB TOTAL e-mail space on the server. So if you get several big attachments over the weekend, and you haven't emptied the Recycle and Sent folders lately, you may find that you can't reply to messages until you clean out some of the trash.
It gets worse -- at 100MB, you can not receive mail at all. Many has been the time I've wanted to send 100 1MB files to the twelfth bozo who forgot not to "Reply to All" when telling some other bozo not to "Reply to All" on a mass mailing.
My hat's off to the folks who put together their site. The front page is a little vague -- the link to the main info isn't obvious, but:
a) The technology is presented in a non-condescending, comprehensible manner
b) Images are clear and consise
c) No Flash used
So they're spending their money in the right places -- which is where I'd want to invest the VC money I don't have.
rjstanford said:
Urk -- time for me to go back to micro(processor) economics class again.
But let's see what happens when supply and demand can actually be measured. We may see processor prices go up when the value is higher.
Truly, we probably need to price it in gigaflops or something like that. Just figuring the amortization of your PC over three years, an average CPU chip price on a higher-end (2+GHz P4) machine being $300 (generous, maybe counting some of the RAM and mobo cost), divided by seconds per year... about $0.000003 per CPU second. I'll leave the calculation of price per billion floating point operations to somebody with a P4 spec manual handy.
With the millions of PCs sitting around with "Idle" as the busiest process, imagine getting a penny or so per CPU second, selling CPU time on the open market to the
Now, you have a value for CPU time on the open market. You should be able to
For a reference of a future society that uses this, see Greg Egan's "Distress" and perhaps "Permutation City"
Can you imagine that rhino's mom's embarrassment?
Buy Crelm toothpaste today! Don't end up fossilized like this poor sap!
% Save this as dragon.ps for 15 pages of
% fractal iteration -- commented even!
% define constant of 1/sqrt(2)
/Scalefactor 1 2 sqrt div def
% Define Fractal subroutine
% usage: lvl Fractal stroke
% Examples below are as if called with a level of 5
/Fractal { % 5
dup % 5 5
0 eq % 5 false
{
% True condition: draws line segment
pop 300 0 rlineto % -
}
{
% False condition: recurse routine
% set the scale factor
Scalefactor dup scale % 5
% On alternate iterations, level is set negative. When negative, reverse the angles
dup -90 exch % 5 -90 5
0 lt % 5 -90 false
{ neg exch neg exch } if % 5 -90 false
% Recurse one level lower
dup 2 div % 5 -90 -45
rotate exch 1 sub % -90 4
% Actually call myself again
dup Fractal % -90 4
exch dup neg % 4 -90 90
rotate exch neg % -90 -4
% Call second time for second stroke
Fractal % -90
2 div % -45
% set things back to the original scale and rotation
rotate % -
1 Scalefactor div dup scale % -
}
ifelse
} bind def
% Loop to iterate 15 pages of fractal
currentlinewidth 4 div setlinewidth
0 1 15 { 200 400 moveto Fractal stroke showpage } for
Certainly there are other lessons to be learned. IMHO, the biggest bubble-blower is the IPO: in one day, a company's stock could increase in value 20 times. Sure it'd deflate the next week, but the rush of investors brought up the cost of every associated stock.
Amazon and Yahoo bought a lot of startups with that cash, other companies execs I'm sure sold out on their newfound paper wealth, while the average customer asked why he couldn't buy at the IPO price.
Who's at fault there? The analysts who priced the stock so low to begin with? Probably not, when the long-term outlook isn't that far from their predictions. The SEC? Maybe a little bit, but Adam Smith is spinning in his grave over the thought that we should hold back the invisible hand.
In the late '80s, there was a sweet Forth implementation for the Mac called Mach 2. It produced native 68000 code -- unusual because most Forths produced an interpreted byte-code, but possible because of the 68000's stack orientation -- and was cheap (about $50).
While it wasn't the easiest thing in the world to use for building complete GUI apps, it was a great experimental tool because it was essentially an interpreted assembler/disassembler! You could experiment with OS traps that were recently published but hadn't made it to other compiler implementations, and see what machine opcodes would do the job minimally.
You could then take those opcodes and drop them into, say Turbo Pascal (which was barely supported by Borland) as inline machine instructions. Way cool.
The other place where Forth came in handy was a couple several years later when learning PostScript: as a stack-based language, PostScript was a cinch to pick up. Of course, if you've been using RPN calculators, it shouldn't be too bad either.
Forth may be a little low-level in these days when Perl and Python provide such abstract data types, but it makes you think closer to the hardware. When hardware control is an issue (in devices like telescopes, barcode readers, etc.), Forth beats programming in assembler by a long shot.