Very good, I agree with your general premise. I don't think Telco's deserve special protection from innovators...
But you say:
Modern customers are happy to pay for bandwidth. Burst bandwidth, commited bandwidth, quality of service. These are the things a customer will pay for. Charge by the minute, charge by the megabyte and you are dead.
But charging by the minute and/or by the bytes is just a form of burst/commited bandwidth and quality-of-service...
The key point is "quality of service".
If you have an always-on, commited, full bandwidth, for a fixed (buy very high) fee, you're essentially charged by the minute AND by the megabyte, whether you use them or not. But that's the price you pay for the highest quality-of-service.
If, OTOH, you're "unlimited" access is aggregated with 100+ webhogs in your neighborhood, and has an uptime of only 92%, you'll probably pay a much lower fee for your "minute" or "bytes". In exchange, you're accepting a much lower quality-of-service.
From an information-transport perspective, a telephone line is fundamentally no different from a wireless network or a fiber-optic drop -- it offers a certain amount of bandwidth and quality-of-service -- in the absence of artificial barriers (monopolies), the price should rise/drop to reflect this.
Unix/Linux does this for you automatically. The disk caching functionality will keep the disk blocks belonging to recently used
programs in memory
You can additionally turn on the "sticky bit" to improve program loading performance using "chmod +t filename".
From the info page for chmod:
3. save the program's text image on the swap device so it will load
more quickly when run (called the "sticky bit"). For directories
on some systems, prevent users from removing files that they do
not own in the directory; this is called making the directory
"append-only".
That is, when the program terminates, reclaim the memory, but keep the program "text" in swap. For small programs, this cuts down on the text-load overhead. Let's say you had a script that calls grep and sed a gazillion times (instead of writing it all in perl) -- with the sticky bit, grep and sed would load-and-fixup only once for each program.
Hmmm... from looking around the archives, it looks like Linux might (or might not) ignore the sticky bit... It looks like some research is in order here...
Of course, these guys are now talking about using wireless ethernet to carry the traffic; but the idea of radio peer-to-peer has been around. Heck, look in the config for linux kernel, and you'll see the amateur-radio AX.25 packet radio support.
It used to be an early form of 2D barcodes... I think it was called something like the Cauzin strip... Sounded neater in theory than in practice. The decoder was too expensive to bother with, and dot-matrix printers (at the time) has lousy dot density for "hobbyist" use...
It'd be cool if someone can reverse-engineer the CueCAT for normal barcode scanning...
If the CueCAT is a standard wedge barcode decoder, I'm sure someone can hack their way around the software to extract the desired barcode data...
OTOH, if the "wedge" only captures the raw barcode bitmap, and requires the "CueCAT driver" to decode the barcode, someone has to write a barcode decoding algorithm...
FWIW, I wrote a Code 39 and Interleaved 2 of 5 decoder in college... It does NOT decode UPC's, though. If you're interested, you can get it here.
The source-code zip-file has a password: "timeline". The password is there because I normally release it as "postcard-ware"... (A little obnoxious, I know, but I've gathered some beautiful postcards from all over the world for this... And, really, anyone could have asked me to e-mail them the password, and I would.)
Please be gentle! It's old sleepless-newbie-student C code, but it did work. If someone can spend time to port it to Windows and the CueCAT, that'll be really cool... I don't have the time right now.:-(
Slashdot Mirror
Very good, I agree with your general premise. I don't think Telco's deserve special protection from innovators...
But you say:
But charging by the minute and/or by the bytes is just a form of burst/commited bandwidth and quality-of-service...
The key point is "quality of service".
If you have an always-on, commited, full bandwidth, for a fixed (buy very high) fee, you're essentially charged by the minute AND by the megabyte, whether you use them or not. But that's the price you pay for the highest quality-of-service.
If, OTOH, you're "unlimited" access is aggregated with 100+ webhogs in your neighborhood, and has an uptime of only 92%, you'll probably pay a much lower fee for your "minute" or "bytes". In exchange, you're accepting a much lower quality-of-service.
From an information-transport perspective, a telephone line is fundamentally no different from a wireless network or a fiber-optic drop -- it offers a certain amount of bandwidth and quality-of-service -- in the absence of artificial barriers (monopolies), the price should rise/drop to reflect this.
Unix/Linux does this for you automatically. The disk caching functionality will keep the disk blocks belonging to recently used programs in memory
You can additionally turn on the "sticky bit" to improve program loading performance using "chmod +t filename".
From the info page for chmod:
3. save the program's text image on the swap device so it will load more quickly when run (called the "sticky bit"). For directories on some systems, prevent users from removing files that they do not own in the directory; this is called making the directory "append-only".That is, when the program terminates, reclaim the memory, but keep the program "text" in swap. For small programs, this cuts down on the text-load overhead. Let's say you had a script that calls grep and sed a gazillion times (instead of writing it all in perl) -- with the sticky bit, grep and sed would load-and-fixup only once for each program.
Hmmm... from looking around the archives, it looks like Linux might (or might not) ignore the sticky bit... It looks like some research is in order here...
Of course, these guys are now talking about using wireless ethernet to carry the traffic; but the idea of radio peer-to-peer has been around. Heck, look in the config for linux kernel, and you'll see the amateur-radio AX.25 packet radio support.
It used to be an early form of 2D barcodes... I think it was called something like the Cauzin strip... Sounded neater in theory than in practice. The decoder was too expensive to bother with, and dot-matrix printers (at the time) has lousy dot density for "hobbyist" use...
It'd be cool if someone can reverse-engineer the CueCAT for normal barcode scanning...
If the CueCAT is a standard wedge barcode decoder, I'm sure someone can hack their way around the software to extract the desired barcode data...
OTOH, if the "wedge" only captures the raw barcode bitmap, and requires the "CueCAT driver" to decode the barcode, someone has to write a barcode decoding algorithm...
FWIW, I wrote a Code 39 and Interleaved 2 of 5 decoder in college... It does NOT decode UPC's, though. If you're interested, you can get it here.
The source-code zip-file has a password: "timeline". The password is there because I normally release it as "postcard-ware"... (A little obnoxious, I know, but I've gathered some beautiful postcards from all over the world for this... And, really, anyone could have asked me to e-mail them the password, and I would.)
Please be gentle! It's old sleepless-newbie-student C code, but it did work. If someone can spend time to port it to Windows and the CueCAT, that'll be really cool... I don't have the time right now. :-(