Let's see...I don't have the book in front of me, but a dim recollection seems to bring back:
1) bunches of boys spending all their time together NAKED. 2) The scenes in battle-room or whatever where there would be a ball of boys around one who, after much tension, is ejected (ejaculated?) at the other team. 3) The fact that the aliens are called Buggers. (look down to the slang definition about sodomy.)
Just go ahead and read the book again. It's really quite amazing to notice. And I'm not just saying that because I was an English Major.
Bandwidth is a limited commodity. There are only so many bits that can travel at any given moment.
But, like airplane seats and hotel rooms, unsold bandwidth is a 100% loss. Bandwidth that went unsold yesterday can not be sold tomorrow. The trick is always selling all of the inventory at as good a price as you can get for it.
Supply is exceeded by demand, so the price goes up until people dont want to pay anymore.
But not all the time. There are plenty of hours every week in which huge amounts of bandwidth lays idle. That's money down the drain. Sure, giving away bandwidth for next to nothing is stupid on a Thursday afternoon. That's prime-net-time. But really, there's no reason I shouldn't be able to plop down in Starbucks on Saturday night at 7:30 and surf to my heart's content. It's not like anyone ELSE is using it. I'm not saying I should be able to steal it, but I shouldn't have to pay an arm and a leg for it either.
That's an interesting thought, but I know of no evidence that it might be true. The passage of time is not a function of the speed of light.
It's not only an interesting thought, it's an axiom. Time doesn't mean anything without a clock. That clock is the movement of light. So the speed of light may change, but it's always the "same", because how we measure it has also changed.
Everything that's written correctly, session don't have to rely on cookies. The other most commond method is url rewritting.
Ugh. Please. URL rewriting is about as ugly a way to track sessions as I can imagine. Yes, it works. Yes, it works without cookies. But as soon as people start emailing links to other people, it all goes to hell. I've been there, I've done it, and I won't do it again.
If this release of Netscape is based on Mozilla.94, ad Mozilla.95 is out, why should I use the Netscape release?
For slashdot readers, probably not much. But I know I wouldn't want my DAD downloading the latest nightly mozilla builds. It wouldn't take long for him to hit a release that messes up his profile in a way he wouldn't know how to fix. I *LOVE* the advances that have been made in Mozilla since 0.9.4, but there have been several builds that really show the not-meant-for-the-masses reality of Mozilla-builds.
Netscape, love 'em or hate 'em, are doing the RIGHT thing by taking branches of Mozilla and stabilizing them into commercial releases. Anything else would be too much like the 2.4 kernel.
Everyone and their geeky brother with a midi synthesizer and a few years in high school band thinks they're a musician. That's why there are several trillion HORRIBLE songs on MP3.com. Weeding out some of the over-supply on MP3.com will HELP those musicians who are actually worth listening to. I mean come on, does anyone really think we NEED someone who is willing to combine Duran Duran, Rush, Nine Inch Nails, and Vivaldi?
If you want to write bad songs and put them online, that's fine. But expecting to make a noticable amount of money off of it is unlikely. Just because MP3.com was willing to pay more people more money than they deserved for so long doesn't make it a crime to stop doing it.
Now that said, the reason many Americans don't like diesel cars is that diesel is thicker and less volatile, and thus
diesel engines don't start as easily, particularly in cold climates.
I took my VW Golf TDI to Maine this winter for the weekend. It sat for two days in well below freezing temperatures and it started just fine. That's what the glow plugs[*] are for.
* Glow plugs are basically a pre-heater for your engine. You turn the key part way, wait for the little light to go off and then start the car. A diesel has a much larger battery than a typical gasoline-powered car in order to support the glow plugs.
you offer no reasoning
whatsoever as to why your "method" is better than using cookies.
That's because I wasn't trying to say IP counting is better than cookies. I was saying that for most sites, counting IPs is more than good enough. Cookie tracking and IP counting are both reasonably accurate.
I'll gladly submit to better ideas, if only you can show me the flaws in my own arguments
and convince me of yours.
I wasn't trying to change anyone's mind. I was just trying to answer the original question. Cookies are a great way to track (and count) users, but they have nothing to do with the original question.
Q: "How do you map IPs to users?" A: "Use cookies!"
They mean well, but they don't live in the real world. I on the other hand mean well AND live in the real world, so here are two reasonable ways to handle it. They both should give similar -- but not identical -- numbers. Either of which is good enough for anyone with reasonable expectations.
1) Count the number of unique IP addresses you see every half hour. Simple, fast, easy. And reasonably accurate.
2) A series of hits from a single IP can be considered a single user if there are no gaps more than five minutes between hits. Count up the number of these bunches of hits you see and you get the number of people. Hard and slow, but reasonably accurate.
Neither of these will really give you the people that came to your site, but they definitly give you a good guess. They can't see stuff hidden behind proxies (but neither can anyone else) and they don't deal with IP addresses that change during a single session. But compare even THIS data to what TV advertisers get from Neilsen and you will NEVER feel like you need to drop a cookie on every one of your users.
I use the first version to report traffic for a 4-million pageview a day website and it works just fine. And if your boss doesn't like it, beat some reasonable expectations into him or her.
This is all VERY misleading. The fact of the matter is, US public schools produce some of the best students (second only to Sigapore) and some of the worst students. The problem with averaging it out across an entire country is that everything becomes, well, average.
The fact of the matter is, the United States does VERY poorly when it tries to educate poor, urban, black kids but it does amazingly well when it tries to educate middle-class, suburban white kids. And most of that difference can be traced back to, yes, money. The more money a school district can spend per student -- for materials, books, GOOD TEACHERS, etc -- the better the students do.
US schools are horrible and they're great. They are better than most countries and worse than most countries. Your statistics, while convincing on the surface, do nothing to explain the REAL issues with public school -- and the rest of American society -- today.
How about some numbers? That kinda bullshit hyperbole is what makes me want to bitch-slap environmentalists these days.
If you took the time to read the article you'd see that the people who need bitch-slapping are the anti-environmentalists. They are the ones who are implying a huge increase in energy demand (that isn't there) and a need for a drastic rollback of environmental regulations to cope with said increase.
...it's the overhead. If you can make due without the "generic" Perl/HTML pieces like Embperl you are probably going to mainly notice a difference in memory. You probably won't notice a speed difference between a purely custom interface written directly for mod_perl versus a more generic one from CPAN. But what you will notice is that the memory requirements of the generic one will be higher.
But since a mod_perl enabled Apache process is already vastly larger than a non-mod_perl process, the little bit of overhead for Embperl or whatever won't make much of a difference. The REAL trick is to make sure that ONLY dynamic content is served from mod_perl processes and everything else is served from slim apache processes. mod_rewrite, mod_proxy, and mod_include will be very helpful for this.
And what content exactly were you expecting from the Mission Impossible: 2 website? If a website is worth visiting, they can most often be trusted to do the right thing. And sometimes the right thing is a full page Flash animation. It works more reliably than most DHTML and uses a reasonable amount of resources on the client side and a fair amount of bandwidth on the way down. No matter how good a JavaScript programmer you are, the George Liqour Program is probably still better done in Flash.
That's not to say I support creating entire sites in Flash...That's dumb too. But anyone with content worth looking at is probably going to pick the right tool for the job. And if they make a mistake, send them a nice email and they probably will fix it (or at least think twice before doing it again!)
We use mod_perl all over the place at PBS Online and are very happy with it. If you're careful and modularize your code, you can mix up normal Perl-based CGI, mod_perl based cgi-registry stuff and something like HTML::Embperl very easily. Embperl is nice for templating, as long as you don't go overboard with the amount of perl code you put in the HTML...
My suggestion is to write as much as you can in.pm modules (perl objects if you're really looking for maintainability) and then just do loops and stuff in your templating language. That way, you can easily write command-line interfaces to the same functions you're calling from your HTML pages...which makes testing MUCH easier and faster.
As for speed...mod_perl has eliminated perl as the bottle neck for most requests for us...database queries are much slower than the a reasonable perl function, so you can ignore anyone who says that perl is too slow for dynamic, high traffic stuff.
If you have to fork a process in order to run your script, you are not going to scale particularly well. It doesn't matter if you're writing in Perl, C, Java, or Lisp.
In my experience, the performance gains from compiling your code into the server (writing a module from scratch in C for Apache, or using mod_perl, mod_php, or Java Servlets) are by far the most noticable.
Once you make that fundamental step, then you can start worrying about Perl vs Java vs C.
Go to PBS Online. Go into "Station Finder", enter your zipcode (or browse the by-state listings), pick your station, and click on "Remember My Station". From then on you can get local TV Schedules specific to your particular PBS station, as well as other station-specific things.
(Yes, I work for PBS Online. Yes, I wrote the Station Finder and TV Schedules areas. And yes, it all runs under Apache/Perl/MySQL.)
The *REAL* reason they don't want you to make digital copies of digital source has nothing to do with piracy. They want to ensure that eventually, when a new media format arrives, you are not allowed to take your existing media and copy it to the new format. The music industry has made a TREMENDOUS amount of money from people buying on CD music they already owned on LP/8Track/Cassette.
If there is a new format (and internet distribution counts as a new format), they want to make sure they can sell it as such. Whether they have a leg to stand on or not must be left to the lawyers.
I personally will be so happy when we get some sort of transportation system that does not depend on people to do all of the controlling of the vehicles.
There is already a great way to reduce the number of individuals controlling their cars in unpredictable ways. They're called buses.
These automation systems are just cop-outs for a society unwilling to commit to a modern transportation infrastructure.
As long as you use an encryption scheme based on both a pass phrase and a private key, getting one or the other is ok as long as they don't get both. Just keep your private key on a floppy and don't leave it unattended.
Slashdot Mirror
My brother-in-law and I carved a Space Invader and an intergalactic Hitchhiker, respectively.
Let's see...I don't have the book in front of me, but a dim recollection seems to bring back:
1) bunches of boys spending all their time together NAKED.
2) The scenes in battle-room or whatever where there would be a ball of boys around one who, after much tension, is ejected (ejaculated?) at the other team.
3) The fact that the aliens are called Buggers. (look down to the slang definition about sodomy.)
Just go ahead and read the book again. It's really quite amazing to notice. And I'm not just saying that because I was an English Major.
It's also on the U.S. Naval Academy's reading list for prospective Marine Corps officers.
I find it very amusing that a book filled with homosexual symbolism is on the reading lists for our country's premier homophobic organizations.
But, like airplane seats and hotel rooms, unsold bandwidth is a 100% loss. Bandwidth that went unsold yesterday can not be sold tomorrow. The trick is always selling all of the inventory at as good a price as you can get for it.
Supply is exceeded by demand, so the price goes up until people dont want to pay anymore.
But not all the time. There are plenty of hours every week in which huge amounts of bandwidth lays idle. That's money down the drain. Sure, giving away bandwidth for next to nothing is stupid on a Thursday afternoon. That's prime-net-time. But really, there's no reason I shouldn't be able to plop down in Starbucks on Saturday night at 7:30 and surf to my heart's content. It's not like anyone ELSE is using it. I'm not saying I should be able to steal it, but I shouldn't have to pay an arm and a leg for it either.
Pre-emptable kernel: Bringing the multitasking of MacOS 9 to Linux since 2.3!
It's not only an interesting thought, it's an axiom. Time doesn't mean anything without a clock. That clock is the movement of light. So the speed of light may change, but it's always the "same", because how we measure it has also changed.
Ugh. Please. URL rewriting is about as ugly a way to track sessions as I can imagine. Yes, it works. Yes, it works without cookies. But as soon as people start emailing links to other people, it all goes to hell. I've been there, I've done it, and I won't do it again.
For slashdot readers, probably not much. But I know I wouldn't want my DAD downloading the latest nightly mozilla builds. It wouldn't take long for him to hit a release that messes up his profile in a way he wouldn't know how to fix. I *LOVE* the advances that have been made in Mozilla since 0.9.4, but there have been several builds that really show the not-meant-for-the-masses reality of Mozilla-builds.
Netscape, love 'em or hate 'em, are doing the RIGHT thing by taking branches of Mozilla and stabilizing them into commercial releases. Anything else would be too much like the 2.4 kernel.
Everyone and their geeky brother with a midi synthesizer and a few years in high school band thinks they're a musician. That's why there are several trillion HORRIBLE songs on MP3.com. Weeding out some of the over-supply on MP3.com will HELP those musicians who are actually worth listening to. I mean come on, does anyone really think we NEED someone who is willing to combine Duran Duran, Rush, Nine Inch Nails, and Vivaldi?
If you want to write bad songs and put them online, that's fine. But expecting to make a noticable amount of money off of it is unlikely. Just because MP3.com was willing to pay more people more money than they deserved for so long doesn't make it a crime to stop doing it.
I took my VW Golf TDI to Maine this winter for the weekend. It sat for two days in well below freezing temperatures and it started just fine. That's what the glow plugs[*] are for.
* Glow plugs are basically a pre-heater for your engine. You turn the key part way, wait for the little light to go off and then start the car. A diesel has a much larger battery than a typical gasoline-powered car in order to support the glow plugs.
That's because I wasn't trying to say IP counting is better than cookies. I was saying that for most sites, counting IPs is more than good enough. Cookie tracking and IP counting are both reasonably accurate.
I'll gladly submit to better ideas, if only you can show me the flaws in my own arguments and convince me of yours.
I wasn't trying to change anyone's mind. I was just trying to answer the original question. Cookies are a great way to track (and count) users, but they have nothing to do with the original question.
Q: "How do you map IPs to users?" A: "Use cookies!"
They mean well, but they don't live in the real world. I on the other hand mean well AND live in the real world, so here are two reasonable ways to handle it. They both should give similar -- but not identical -- numbers. Either of which is good enough for anyone with reasonable expectations.
1) Count the number of unique IP addresses you see every half hour. Simple, fast, easy. And reasonably accurate.
2) A series of hits from a single IP can be considered a single user if there are no gaps more than five minutes between hits. Count up the number of these bunches of hits you see and you get the number of people. Hard and slow, but reasonably accurate.
Neither of these will really give you the people that came to your site, but they definitly give you a good guess. They can't see stuff hidden behind proxies (but neither can anyone else) and they don't deal with IP addresses that change during a single session. But compare even THIS data to what TV advertisers get from Neilsen and you will NEVER feel like you need to drop a cookie on every one of your users.
I use the first version to report traffic for a 4-million pageview a day website and it works just fine. And if your boss doesn't like it, beat some reasonable expectations into him or her.
print join("\t", qw(reserved monitorDepth browserFontSize connectionSpeed connectionType monitorHorz monitorVert browserViewHorz browserViewVert popID sandboxVersion)), "\n";
while(<>) {
($misc, $monx, $mony, $browsx, $browsy,
$popid, $sand) = map {hex} unpack("A8 A4 A4 A4 A4 A8 A8", $_);
$res = ($misc & 0xffc0000) >> 18;
$dep = ($misc & 0x003fc00) >> 10;
$fon = ($misc & 0x0000380) >> 7;
$spe = ($misc & 0x0000070) >> 4;
$typ = ($misc & 0x000000f);
print join("\t", $res, $dep, $fon, $spe, $typ, $monx, $mony, $browsx, $browsy, $popid, $sand), "\n";
}
This is all VERY misleading. The fact of the matter is, US public schools produce some of the best students (second only to Sigapore) and some of the worst students. The problem with averaging it out across an entire country is that everything becomes, well, average.
The fact of the matter is, the United States does VERY poorly when it tries to educate poor, urban, black kids but it does amazingly well when it tries to educate middle-class, suburban white kids. And most of that difference can be traced back to, yes, money. The more money a school district can spend per student -- for materials, books, GOOD TEACHERS, etc -- the better the students do.
US schools are horrible and they're great. They are better than most countries and worse than most countries. Your statistics, while convincing on the surface, do nothing to explain the REAL issues with public school -- and the rest of American society -- today.
If you took the time to read the article you'd see that the people who need bitch-slapping are the anti-environmentalists. They are the ones who are implying a huge increase in energy demand (that isn't there) and a need for a drastic rollback of environmental regulations to cope with said increase.
Ender's Game:
I don't know if he's homophobic or homosexual. All I know is that there is way more symbolism in that book than is apparent at first glance.
...it's the overhead. If you can make due without the "generic" Perl/HTML pieces like Embperl you are probably going to mainly notice a difference in memory. You probably won't notice a speed difference between a purely custom interface written directly for mod_perl versus a more generic one from CPAN. But what you will notice is that the memory requirements of the generic one will be higher.
But since a mod_perl enabled Apache process is already vastly larger than a non-mod_perl process, the little bit of overhead for Embperl or whatever won't make much of a difference. The REAL trick is to make sure that ONLY dynamic content is served from mod_perl processes and everything else is served from slim apache processes. mod_rewrite, mod_proxy, and mod_include will be very helpful for this.
--Mike
As are infant mortality rates below 10%, weekends, (relatively) painless dentistry, heart surgery, antibiotics...
Just because it's a recent invention doesn't mean it's invalid.
That's not to say I support creating entire sites in Flash...That's dumb too. But anyone with content worth looking at is probably going to pick the right tool for the job. And if they make a mistake, send them a nice email and they probably will fix it (or at least think twice before doing it again!)
My suggestion is to write as much as you can in .pm modules (perl objects if you're really looking for maintainability) and then just do loops and stuff in your templating language. That way, you can easily write command-line interfaces to the same functions you're calling from your HTML pages...which makes testing MUCH easier and faster.
As for speed...mod_perl has eliminated perl as the bottle neck for most requests for us...database queries are much slower than the a reasonable perl function, so you can ignore anyone who says that perl is too slow for dynamic, high traffic stuff.
If you have to fork a process in order to run your script, you are not going to scale particularly well. It doesn't matter if you're writing in Perl, C, Java, or Lisp.
In my experience, the performance gains from compiling your code into the server (writing a module from scratch in C for Apache, or using mod_perl, mod_php, or Java Servlets) are by far the most noticable.
Once you make that fundamental step, then you can start worrying about Perl vs Java vs C.
(Yes, I work for PBS Online. Yes, I wrote the Station Finder and TV Schedules areas. And yes, it all runs under Apache/Perl/MySQL.)
The *REAL* reason they don't want you to make
digital copies of digital source has nothing to do with piracy. They want to ensure that eventually, when a new media format arrives, you are not allowed to take your existing media and copy it to the new format. The music industry has made a TREMENDOUS amount of money from people buying on CD music they already owned on LP/8Track/Cassette.
If there is a new format (and internet distribution counts as a new format), they want to make sure they can sell it as such. Whether they have a leg to stand on or not must be left to the lawyers.
There is already a great way to reduce the number of individuals controlling their cars in unpredictable ways. They're called buses.
These automation systems are just cop-outs for a society unwilling to commit to a modern transportation infrastructure.
As long as you use an encryption scheme based on both a pass phrase and a private key, getting one or the other is ok as long as they don't get both. Just keep your private key on a floppy and don't leave it unattended.