I went to a presentation a few years ago by a pair of eBay's senior engineers where they were discussing their architecture and technology. They explained their Java-on-Windows two-tier architecture (web front-ends which are handling all of the business logic, database backends, little-to-no caching, etc). They explained how they have pools of servers for handling different page types (i.e. search vs. gateway vs. help, etc) and how they sometimes have brownouts in some pools because they mis-predicted the number of servers they needed in that pool.
During the Q&A, somebody asked them, "what's the biggest challenge that you guys face?"; the response was "fitting enough information in the browser's cookie... 4k really isn't enough information for us". A follow-up question was asked about why they didn't just use a session-id key and store as much data as they want in a database or cache, etc. They basically admitted that they didn't have the technical strength to build something like that at their scale.
I asked them why they allow users to post JavaScript in their posts as it basically turns all of eBay into a cross-site scripting bug. I know for a fact that sellers have been able to include JS in their posts which can record the max-bid of the buyer. Sure, it's against the TOS, but only if they catch it. Their response was that it's what their customers (read sellers) want.
The point I'm getting to is that eBay, despite having one of the most popular websites in the world employs some bass-ackward technical solutions and business policies. What's reported in this doesn't surprise me at all.
If it's only vehicle location track, how is this different than having the police tail the vehicle or follow it via helicopter, etc. This seems like a lower-cost mechanism for doing the same thing. Is there more to it than that?
It's due to trademark laws... the IP lawyers where I work remind us that trademarked brand terms should be used as adjectives and not nouns (despite the fact that they're generally referred to as nouns amongst "lay people"). For instance, Apple refers to the iPod(R) as the "iPod(R) mobile digital device" if you dig deeply into their docs.
It's the same thing for Lego... they're Lego(R) bricks, despite the common vernacular of Legos.:D
Back in the day (about a decade ago), you could "smurf" folks, which is a form of reflective amplification. The process was fairly simple: you'd ping a network's broadcast address with a packet spoofed to appear to come from your victim. At the time, most networks weren't filtering the broadcast traffic. As a result all the hosts on that network would respond to the ping. Back in the days of 14.4 modems, you could easily blow somebody offline while generating a very tiny volume of traffic.
---> ping (src: victim [spoofed], dest: broadcast address of large network) <=== large number of icmp responses (src: addresses in large network, dest: victim)
I think that you're partly right about the durability of goods, but there's so much more to Amazon's ability to extend the long-tail.
For one, there's the issue of quantity. If Amazon wants to guarantee stock on a really obscure book, it needs to have 1 or two copies of that book in one warehouse. If a brick-and-mortar wants to guarantee stock of the same book, then need 1-2 copies in every/most stores. For large brick-and-mortar stores, that could be thousands or even 10s-of-thousands of copies of that book. Of course... then you can add print-on-demand to the mix and that changes the picture quite a bit as well; then Amazon can stock 0 inventory of that book. But print-on-demand is another story, and applicable only to some categories (books, cds, dvds, etc).
Another big win is prediction. Amazon does a fairly good job of predicting demand and ordering accordingly. Additionally, in cases where demand exceeds local inventory supply, Amazon can generally request a drop-shipment from the supplier. While there's nothing stopping your local brick-and-mortar from doing the same thing, it's generally much more transparent to the consumer when a random brown box shows up on their door.
An interesting metric in the retail space is the number of "inventory turns" per year, which roughly translates to "how often do we completely empty and re-fill the items on our shelves". Amazon does it more than once a month (see http://blogs.zdnet.com/BTL/?p=8591); K-mart does it about 4 times a year. Walmart's closer to 7 times per year. Interesting, eh?
Agreed. I'd specifically recommend the "Wonder Shaper" http://lartc.org/wondershaper/ from the kind, albiet insane, folks at the Linux Advanced Routing & Traffic Control site.
Careful though; spending too much time there might cause mental grief (for example, go read Section 12.1.3 of the LARTC HOWTO), but I digress.
On the other hand, if you're fluent in this and/or like working in the kernel networking stack, shoot me an email/message, cause I've got a fun job for you.
This sounds like a reasonable use for Amazon's Simple Storage Service (S3). See http://aws.amazon.com/s3 for more info, but it's a web service data storage solution that charges for usage ($0.15/GB/month for storage + $0.20/GB for transfer) that's redundant and scalable and allows you to store an "unlimitted" amount of data. You can take advantage of Amazon's infrastructure and avoid needing to hire people to maintain a fleet of storage servers.
Having slowly moved in the other direction - dorm room to apartment with roommmates to 700 sqft "1+den" aparment to the 850 sqft 2 bedroom condo that I own now - I can tell you that it's all just a matter of planning and organization. Living in small spaces is a matter of efficiently using the space that you have. The gotcha, of course, is doing this while not making your place feel cramped.
Everything has a place. Make sure that everything you own has a place. In small spaces, sometimes you have to sacrifice a little bit of "logical placement" for some "practical placement". For example, I have my pile of extra batteries and spare lightbulbs in a drawer in the nightstand of my bedroom. Does this make sense? Not really; they should probably be in a utility closet or something, but, they fit well there and there was nothing else using that space. The important part is that they've got a place and they're not cluttering up another area.
Efficient use of furniture. When possible try to use furniture that has built-in storage. For example, an end table with a drawer or two can be really useful for storing all sorts of things. Think in 3D. If a piece of furniture is occupying some of your precious square-footage, try to make the best possible use of that space. Storing infrequently used items in drawers or underneath an end-table with a table cloth over it (for example) can make a big difference.
Shelving. You'd be amazed how much you can store on a couple of rows of shelves. If you're not storing books/trinkets or other "decorative" things, you can find wall-mounted book-cases with doors to hide your crap.
Density. In areas that are more-or-less designated for storage (closets, etc), pack densly, but wisely. Well-labelled boxes (like shoe-boxes) can be great for storing all sorts of stuff in a dense manner.
Organization. This one is a big one. Keeping track of where all your stuff is can be tricky. I highly recommend labelling storage containers and remembering to put back what you took out when you're done. When you're stuck in a small space, you'll be amazed how many things you own that you just don't use regularly. Keeping these things accessible but out of the way allows you to retain what you own and now feel too cluttered.
You are correct. I guess my brain slipped out of "statistics mode" into "calculus mode"... I should have said "as the frequency approaches 1"... not "infinity".
It's also worthwhile to note that I stated that in the case where there's 100 '0' digits and the '0' digit is represented by 1-bit, the average bits/digit was 4.22. I was incorrect. This value should have been 1.266 bits per digit in this case. Again, my huffman values are (0, 1000, 1001, 1010, 1011, 1100, 1101, 11100, 11101, 1111) for 0-9, respectivly. The 1.266 bits per digit value is computed as follows:
(100 digits* 1 bit/digit) + (1 occurance of each digit * 38 bits for these digits/occurance) = 138 bits.
138 bits / 109 occurances = 1.266 bits per digit
The 4.22 bits/digit figure came from the 38 bits for digits 0-9 divided by 9 digits = 4.22. My mistake.
When I stated that "any distribution with 0 occuring at least 27.95% of the time... will perform better than the ideal encoding", I computed that as follows (assume P0 is the probabilty of the digit '0'):
(P0 x 1) + ((1-P0) * 4.22) = 0.2795
What's really interesting, and possibly indicative of a flaw in my math, is that if you perform a huffman encoding in which '0' occurs 30% of the time (just good first approximation of 27.95%), you'll get values these values(00, 0100, 0101, 0110, 0111, 100, 101, 1100, 1101, 111) for 0-9, respectively. Notice that '0' is being represented by a two digit binary value instead of a 1 digit value in my previous example. This works out to 4.06 bits/digit (which makes since, given the lower distribution of '0' digits).
Doing the math as above, you'll find that this is at least as good as ideal any time '0' is present more than 20.48% of the time (since the non-'0' values are smaller, on average, in this scenario, we can have more of them).
Overall, (still assuming an even distribution of non-'0' digits), you're better off using a two-bit representation of '0' when '0' occurs between 20.48% and 35.90% of the time, using a one-bit representation will be better than ideal when '0' occurs 27.95% of the time, but will only be better than the two-bit '0' when it occurs more than 35.90% of the time. Anything less that 20.48% (assuming evenly distributed non-'0' digits), will best be represented with using the ideal 3.32 bits per digit, as described originally.
Assuming that my huffman encoding and my math is correct, you'll get 1-bit digits any time the probability of '0' is strictly greater than 33%. Which is unfortunate, since a 2-bit digit is more optimal at the 33% occurance rate.
So, while huffman encoding is extremely efficient for a problem of this scope, it's not always optimal. Any Huffman experts care to chime in here?
Assuming that the ASCII digits of pi are evenly distributed between '0' and '9', then you should have log2(10) = 3.322 bits per digit. At 3.322 bits per digit and 700MiB (5872025600 bits at 8 bits per byte) we should have about 1,767,655,841
digits. Assuming that they're publishing exactly 1.7 Billion digits, they're within 3.8% of ideal compression, assuming an eactly even distribution of digits.
Where it gets interesting is if there's NOT an even distribution of digits (which I don't believe is actually the case for digits of pi, but humor me). For example, assume that one digit, say 0, occurs 100 times more frequently than each of the other digits, with the remain 9 digis occuring evenly. If you use something like huffman encoding and represent '0' with 1 bit, and the remaining bits with an average of 4.22 bits per digit (based on my back-of-the-envelope huffman encoding), you'd wind up averaging 1.266 bits per digit (100/109 * 1 bit + 9/10 * 4.22 bits). Clearly, as the frequency of this digit approaches infinity, the average bits per digit approachs 1. With the scheme described above, any distribution with 0 occuring at least 27.95% of the time (and an even distribution of the remaining digits), this basic encoding will perform better than the ideal encoding described in the first paragraph. For the curious, my huffman encoded values in this scenario were (0, 1000, 1001, 1010, 1011, 1100, 1101, 11100, 11101, 1111) for 0-9 respectively.
Obviously, the digits of pi are NOT distributed as disproportionately as I mentioned above, so a simple huffman encoding scheme is unlikely to produce better than ideal encoding. In fact, assuming an even distribution of digits, a back-of-the-envelope huffman encoding would yield encoded values of (1100, 1101, 1110, 1111, 000, 001, 010, 011, 100, 101) for 0-9. With this, you'd average 3.4 bits/digit, which is only just over 5% away from ideal encoding (this also agrees with the estimate from above, especially since bzip2 uses huffman encoding).
Of course, huffman encoding is not the only option. You could consider checking for multiple-digit combinations and determining the frequency of each combo. Or you could look at actual bit patterns, which is similar to run-length-encoding.
All of this is discounting the fact that the digits of PI are computable, and thus encoding them can be completely avoided if you're willing to spend considerable resources calculating the values yourself. In this case you need 0 bits per digit (discounting the size of your "decompression program"). This is the most computationally intense option, but yields the most optimal compression ratio.
They aren't giving away the printers to be nice, they're giving away the printers because they make all their money on the ink.
They'll give out free firewalls as soon as they figure out a way to charge you for disposables. So, unless the firewall is going to start holding peoples internet connections hostage until they pay a ransom, I don't think that hardware firewalls will be given away without some gimmick.
The MicroKelvin Lab at the University of Florida does research in the 100uK range. They have the largest ultra-low temperature lab in the world (there's another one like it at Cornell).
They do indicate how many pixels of each of the CMYK ink were used, but they don't seem to inforce it. I don't use much color and they don't complain. The contract that I got into didn't say anything about printing any specific amount of color.. only that I had to print a few thousand pages per month.
Check out www.freecolorprinters.com. It's a special deal run by Xerox for organizations that need to print large volumes of color documents. The rules are basically like this:
You sign up with them and indicate how many pages per month you print on average
If they accept you into the program, they'll ship you a Xerox color laser printer (such as the Phaser 8200) which is completely network ready, etc.
Every month, you send them a form (from the printer) to show them how many pages you printed during the month
After 3 years, the printer is yours!
There are a few strings attached: You have to buy your ink from them. And if you forget to send in the form every month they'll charge you a fee. It comes with 3 years of free service. So if you have any problems, you can just call up and they'll help you out.
Additionally, the black ink is completely free! And if the printer doesn't work out for you, they'll pay to ship it back to them. It's a really great deal!
If you decide to go with them, use my referral number and I'll get $100! (Referral #: 427148). Note: I'm not associated with Xerox in any way other than as a satisfied customer.
There's a company here in town that sells this "glorified bean bag" thing. They've got a site online at www.cordaroys.com where you can see what I'm talking about. They're a bit pricey, but they are SOOOOO friggin' comfortable. Definitely worth checking out. The really cool part is that the padding inside can be converted into a make-shift matress in 15 seconds or so, which is great if you have unexpected company and what not.
In case you didn't know what keiretsu meant either:
A network of businesses that own stakes in one another as a means of mutual security, especially in Japan, and usually including large manufacturers and their suppliers of raw materials and components.
Slashdot Mirror
They spoke at re:Invent and mentioned that Amazon.com has been hosted on EC2 for a number of years: http://www.youtube.com/watch?v=f45Uo5rw6YY
no they're not ;-P
Sites like Amazon have already run into this and have moved away from scripting languages and back to system languages
You know Amazon's running on Perl Mason, right? http://www.masonhq.com/?AmazonDotCom ;-P
I went to a presentation a few years ago by a pair of eBay's senior engineers where they were discussing their architecture and technology. They explained their Java-on-Windows two-tier architecture (web front-ends which are handling all of the business logic, database backends, little-to-no caching, etc). They explained how they have pools of servers for handling different page types (i.e. search vs. gateway vs. help, etc) and how they sometimes have brownouts in some pools because they mis-predicted the number of servers they needed in that pool.
During the Q&A, somebody asked them, "what's the biggest challenge that you guys face?"; the response was "fitting enough information in the browser's cookie... 4k really isn't enough information for us". A follow-up question was asked about why they didn't just use a session-id key and store as much data as they want in a database or cache, etc. They basically admitted that they didn't have the technical strength to build something like that at their scale.
I asked them why they allow users to post JavaScript in their posts as it basically turns all of eBay into a cross-site scripting bug. I know for a fact that sellers have been able to include JS in their posts which can record the max-bid of the buyer. Sure, it's against the TOS, but only if they catch it. Their response was that it's what their customers (read sellers) want.
The point I'm getting to is that eBay, despite having one of the most popular websites in the world employs some bass-ackward technical solutions and business policies. What's reported in this doesn't surprise me at all.
If it's only vehicle location track, how is this different than having the police tail the vehicle or follow it via helicopter, etc. This seems like a lower-cost mechanism for doing the same thing. Is there more to it than that?
It's due to trademark laws... the IP lawyers where I work remind us that trademarked brand terms should be used as adjectives and not nouns (despite the fact that they're generally referred to as nouns amongst "lay people"). For instance, Apple refers to the iPod(R) as the "iPod(R) mobile digital device" if you dig deeply into their docs.
It's the same thing for Lego... they're Lego(R) bricks, despite the common vernacular of Legos. :D
Back in the day (about a decade ago), you could "smurf" folks, which is a form of reflective amplification. The process was fairly simple: you'd ping a network's broadcast address with a packet spoofed to appear to come from your victim. At the time, most networks weren't filtering the broadcast traffic. As a result all the hosts on that network would respond to the ping. Back in the days of 14.4 modems, you could easily blow somebody offline while generating a very tiny volume of traffic.
---> ping (src: victim [spoofed], dest: broadcast address of large network)
<=== large number of icmp responses (src: addresses in large network, dest: victim)
I'd guess that the attack is similar in concept.
I think that you're partly right about the durability of goods, but there's so much more to Amazon's ability to extend the long-tail.
For one, there's the issue of quantity. If Amazon wants to guarantee stock on a really obscure book, it needs to have 1 or two copies of that book in one warehouse. If a brick-and-mortar wants to guarantee stock of the same book, then need 1-2 copies in every/most stores. For large brick-and-mortar stores, that could be thousands or even 10s-of-thousands of copies of that book. Of course... then you can add print-on-demand to the mix and that changes the picture quite a bit as well; then Amazon can stock 0 inventory of that book. But print-on-demand is another story, and applicable only to some categories (books, cds, dvds, etc).
Another big win is prediction. Amazon does a fairly good job of predicting demand and ordering accordingly. Additionally, in cases where demand exceeds local inventory supply, Amazon can generally request a drop-shipment from the supplier. While there's nothing stopping your local brick-and-mortar from doing the same thing, it's generally much more transparent to the consumer when a random brown box shows up on their door.
An interesting metric in the retail space is the number of "inventory turns" per year, which roughly translates to "how often do we completely empty and re-fill the items on our shelves". Amazon does it more than once a month (see http://blogs.zdnet.com/BTL/?p=8591); K-mart does it about 4 times a year. Walmart's closer to 7 times per year. Interesting, eh?
-A
Agreed. I'd specifically recommend the "Wonder Shaper" http://lartc.org/wondershaper/ from the kind, albiet insane, folks at the Linux Advanced Routing & Traffic Control site.
Careful though; spending too much time there might cause mental grief (for example, go read Section 12.1.3 of the LARTC HOWTO), but I digress.
On the other hand, if you're fluent in this and/or like working in the kernel networking stack, shoot me an email/message, cause I've got a fun job for you.
Yeah, basically.
This sounds like a reasonable use for Amazon's Simple Storage Service (S3). See http://aws.amazon.com/s3 for more info, but it's a web service data storage solution that charges for usage ($0.15/GB/month for storage + $0.20/GB for transfer) that's redundant and scalable and allows you to store an "unlimitted" amount of data. You can take advantage of Amazon's infrastructure and avoid needing to hire people to maintain a fleet of storage servers.
http://www.wiretracks.com/
Having slowly moved in the other direction - dorm room to apartment with roommmates to 700 sqft "1+den" aparment to the 850 sqft 2 bedroom condo that I own now - I can tell you that it's all just a matter of planning and organization. Living in small spaces is a matter of efficiently using the space that you have. The gotcha, of course, is doing this while not making your place feel cramped.
Everything has a place. Make sure that everything you own has a place. In small spaces, sometimes you have to sacrifice a little bit of "logical placement" for some "practical placement". For example, I have my pile of extra batteries and spare lightbulbs in a drawer in the nightstand of my bedroom. Does this make sense? Not really; they should probably be in a utility closet or something, but, they fit well there and there was nothing else using that space. The important part is that they've got a place and they're not cluttering up another area.
Efficient use of furniture. When possible try to use furniture that has built-in storage. For example, an end table with a drawer or two can be really useful for storing all sorts of things. Think in 3D. If a piece of furniture is occupying some of your precious square-footage, try to make the best possible use of that space. Storing infrequently used items in drawers or underneath an end-table with a table cloth over it (for example) can make a big difference.
Shelving. You'd be amazed how much you can store on a couple of rows of shelves. If you're not storing books/trinkets or other "decorative" things, you can find wall-mounted book-cases with doors to hide your crap.
Density. In areas that are more-or-less designated for storage (closets, etc), pack densly, but wisely. Well-labelled boxes (like shoe-boxes) can be great for storing all sorts of stuff in a dense manner.
Organization. This one is a big one. Keeping track of where all your stuff is can be tricky. I highly recommend labelling storage containers and remembering to put back what you took out when you're done. When you're stuck in a small space, you'll be amazed how many things you own that you just don't use regularly. Keeping these things accessible but out of the way allows you to retain what you own and now feel too cluttered.
You are correct. I guess my brain slipped out of "statistics mode" into "calculus mode"... I should have said "as the frequency approaches 1" ... not "infinity".
... will perform better than the ideal encoding", I computed that as follows (assume P0 is the probabilty of the digit '0'):
It's also worthwhile to note that I stated that in the case where there's 100 '0' digits and the '0' digit is represented by 1-bit, the average bits/digit was 4.22. I was incorrect. This value should have been 1.266 bits per digit in this case. Again, my huffman values are (0, 1000, 1001, 1010, 1011, 1100, 1101, 11100, 11101, 1111) for 0-9, respectivly. The 1.266 bits per digit value is computed as follows:
(100 digits* 1 bit/digit) + (1 occurance of each digit * 38 bits for these digits/occurance) = 138 bits.
138 bits / 109 occurances = 1.266 bits per digit
The 4.22 bits/digit figure came from the 38 bits for digits 0-9 divided by 9 digits = 4.22. My mistake.
When I stated that "any distribution with 0 occuring at least 27.95% of the time
(P0 x 1) + ((1-P0) * 4.22) = 0.2795
What's really interesting, and possibly indicative of a flaw in my math, is that if you perform a huffman encoding in which '0' occurs 30% of the time (just good first approximation of 27.95%), you'll get values these values(00, 0100, 0101, 0110, 0111, 100, 101, 1100, 1101, 111) for 0-9, respectively. Notice that '0' is being represented by a two digit binary value instead of a 1 digit value in my previous example. This works out to 4.06 bits/digit (which makes since, given the lower distribution of '0' digits).
Doing the math as above, you'll find that this is at least as good as ideal any time '0' is present more than 20.48% of the time (since the non-'0' values are smaller, on average, in this scenario, we can have more of them).
Overall, (still assuming an even distribution of non-'0' digits), you're better off using a two-bit representation of '0' when '0' occurs between 20.48% and 35.90% of the time, using a one-bit representation will be better than ideal when '0' occurs 27.95% of the time, but will only be better than the two-bit '0' when it occurs more than 35.90% of the time. Anything less that 20.48% (assuming evenly distributed non-'0' digits), will best be represented with using the ideal 3.32 bits per digit, as described originally.
Assuming that my huffman encoding and my math is correct, you'll get 1-bit digits any time the probability of '0' is strictly greater than 33%. Which is unfortunate, since a 2-bit digit is more optimal at the 33% occurance rate.
So, while huffman encoding is extremely efficient for a problem of this scope, it's not always optimal. Any Huffman experts care to chime in here?
Assuming that the ASCII digits of pi are evenly distributed between '0' and '9', then you should have log2(10) = 3.322 bits per digit. At 3.322 bits per digit and 700MiB (5872025600 bits at 8 bits per byte) we should have about 1,767,655,841
digits. Assuming that they're publishing exactly 1.7 Billion digits, they're within 3.8% of ideal compression, assuming an eactly even distribution of digits.
Where it gets interesting is if there's NOT an even distribution of digits (which I don't believe is actually the case for digits of pi, but humor me). For example, assume that one digit, say 0, occurs 100 times more frequently than each of the other digits, with the remain 9 digis occuring evenly. If you use something like huffman encoding and represent '0' with 1 bit, and the remaining bits with an average of 4.22 bits per digit (based on my back-of-the-envelope huffman encoding), you'd wind up averaging 1.266 bits per digit (100/109 * 1 bit + 9/10 * 4.22 bits). Clearly, as the frequency of this digit approaches infinity, the average bits per digit approachs 1. With the scheme described above, any distribution with 0 occuring at least 27.95% of the time (and an even distribution of the remaining digits), this basic encoding will perform better than the ideal encoding described in the first paragraph. For the curious, my huffman encoded values in this scenario were (0, 1000, 1001, 1010, 1011, 1100, 1101, 11100, 11101, 1111) for 0-9 respectively.
Obviously, the digits of pi are NOT distributed as disproportionately as I mentioned above, so a simple huffman encoding scheme is unlikely to produce better than ideal encoding. In fact, assuming an even distribution of digits, a back-of-the-envelope huffman encoding would yield encoded values of (1100, 1101, 1110, 1111, 000, 001, 010, 011, 100, 101) for 0-9. With this, you'd average 3.4 bits/digit, which is only just over 5% away from ideal encoding (this also agrees with the estimate from above, especially since bzip2 uses huffman encoding).
Of course, huffman encoding is not the only option. You could consider checking for multiple-digit combinations and determining the frequency of each combo. Or you could look at actual bit patterns, which is similar to run-length-encoding.
All of this is discounting the fact that the digits of PI are computable, and thus encoding them can be completely avoided if you're willing to spend considerable resources calculating the values yourself. In this case you need 0 bits per digit (discounting the size of your "decompression program"). This is the most computationally intense option, but yields the most optimal compression ratio.
One Mach = 1,116 feet per second at sea level
define:mach
Enjoy.
They aren't giving away the printers to be nice, they're giving away the printers because they make all their money on the ink.
They'll give out free firewalls as soon as they figure out a way to charge you for disposables. So, unless the firewall is going to start holding peoples internet connections hostage until they pay a ransom, I don't think that hardware firewalls will be given away without some gimmick.
The MicroKelvin Lab at the University of Florida does research in the 100uK range. They have the largest ultra-low temperature lab in the world (there's another one like it at Cornell).
They do indicate how many pixels of each of the CMYK ink were used, but they don't seem to inforce it. I don't use much color and they don't complain. The contract that I got into didn't say anything about printing any specific amount of color.. only that I had to print a few thousand pages per month.
- You sign up with them and indicate how many pages per month you print on average
- If they accept you into the program, they'll ship you a Xerox color laser printer (such as the Phaser 8200) which is completely network ready, etc.
- Every month, you send them a form (from the printer) to show them how many pages you printed during the month
- After 3 years, the printer is yours!
There are a few strings attached: You have to buy your ink from them. And if you forget to send in the form every month they'll charge you a fee. It comes with 3 years of free service. So if you have any problems, you can just call up and they'll help you out.Additionally, the black ink is completely free! And if the printer doesn't work out for you, they'll pay to ship it back to them. It's a really great deal! If you decide to go with them, use my referral number and I'll get $100! (Referral #: 427148). Note: I'm not associated with Xerox in any way other than as a satisfied customer.
-Andy
Bits can recycle!
Reversible computing,
Wave of the future.
Deleting Data
Creates heat by resistance.
One must not delete!
Instead, transform it.
Reversible instructions
support this concept.
Read data about
Adiabatic circuits.
That's just my two cents.
There's a company here in town that sells this "glorified bean bag" thing. They've got a site online at www.cordaroys.com where you can see what I'm talking about. They're a bit pricey, but they are SOOOOO friggin' comfortable. Definitely worth checking out. The really cool part is that the padding inside can be converted into a make-shift matress in 15 seconds or so, which is great if you have unexpected company and what not.
-Andy
In case you didn't know what keiretsu meant either:
A network of businesses that own stakes in one another as a means of mutual security, especially in Japan, and usually including large manufacturers and their suppliers of raw materials and components.
I'd recommend that the data be petrified... and covered in hot grits!
Me, I'll continue to support artists who don't use distributors who cripple their music, and go see those I like live.
Me, I'll continue to support artists who are naked, petrified, and covered in hot grits.
;-)