Exactly, it's a social science, which should be treated entirely separately from traditional science which can perform experiments that isolate factors and not just rely on historical data. This doesn't change the fact that we're undoubtedly better off with economic theories than we are without them.

The trouble occurs when people who use them are not apprehensive enough of their limitations, specifically that they don't have the same rigorous backing of proper scientific theories. The assumption of perfect markets (perfect information, no barriers to entry, no anti-competitive power) is simply that, it will never exist in real life, people should treat it as such. That doesn't make the notion of the invisible hand any less valid in the vast majority of cases, as it can be readily demonstrated to occur in virtually every free market industry. Unlike traditional sciences though, there are clearly occasional exceptions or hiccups brought about by the assumptions the idea underpins and they should always be kept in mind.

>> ^dag:
I don't think that's related. I get that sometimes too. Ad companies- and even our own, non-ad content - use Content Delivery Networks that replicate things like images, flash files and scripts across a network of servers around the globe- with the goal of directing you to the content that is geographically closest to your location. Sometimes those CDN servers have hiccups or down time.
We use a CDN for our images, CSS files and scripts at static1.videosift.com. Advertisers use something similar. Can you tell what content it's stuck on by looking at the status bar at the bottom of the browser?>> ^rougy:
I don't know if this is related or not, but about 8 out of 10 pages that I open on VS will not load all of the way. They'll just hang there and I have to press the stop button before the page will respond to any mouse clicks.
I've noticed that it tends to happen on pages containing some new Flash-type ads that I haven't seen before.



Thanks for the feedback.

I'm using Opera now, so I can't see which element is hanging up, but I'll play around with FF and see if anything shows up.

Comment hidden because you are ignoring dag. (show it anyway)

I don't think that's related. I get that sometimes too. Ad companies- and even our own, non-ad content - use Content Delivery Networks that replicate things like images, flash files and scripts across a network of servers around the globe- with the goal of directing you to the content that is geographically closest to your location. Sometimes those CDN servers have hiccups or down time.

We use a CDN for our images, CSS files and scripts at static1.videosift.com. Advertisers use something similar. Can you tell what content it's stuck on by looking at the status bar at the bottom of the browser?>> ^rougy:
I don't know if this is related or not, but about 8 out of 10 pages that I open on VS will not load all of the way. They'll just hang there and I have to press the stop button before the page will respond to any mouse clicks.
I've noticed that it tends to happen on pages containing some new Flash-type ads that I haven't seen before.

>> ^lucky760:
Everything should be working fine now. Please let us know if you experience any further difficulty.
We just added a mobile version of the Sift for hand-held devices (very basic initially, but commenting will be added soon) and those changes likely caused a hiccup.


Thanks and good mawning.

Everything should be working fine now. Please let us know if you experience any further difficulty.

We just added a mobile version of the Sift for hand-held devices (very basic initially, but commenting will be added soon) and those changes likely caused a hiccup.

My bad. It wasn't you. It was FFord. I left a message to see if he/she is having the same problem too.

In reply to this comment by campionidelmondo:
Camino is MacOSX only, no? Afraid I couldn't use it then. However, the double-click bug has never been fixed from our end, because it is a bug in FlashBlock, which has been resolved in newer versions. If you're talking about having to double click on the FlashBlock placeholder, then the simple solution would be to upgrade.

In any case, nothing has changed in our code, so if it was working before the problem must be on your end.

In reply to this comment by ant:
Hmm. Are you seeing it in Camino?


In reply to this comment by campionidelmondo:
No, nothing changed.

In reply to this comment by ant:
Bad news. It is back again. Did you change something?

In reply to this comment by campionidelmondo:
Yes, it kinda is. Don't worry, it'll work for you using FlashBlock very soon

In reply to this comment by ant:
Interesting, and the resize is required?

In reply to this comment by campionidelmondo:
4.0 resizes the embeds via JS, which is neccessary because of the dynamic width the content div can have (it streches from 1024 to 1150px in fixed mode and to infinity in loose mode). v3.3 and older had static page widths, so the resizing was done server-side.

In reply to this comment by ant:
Hmm, double clicks? Keep working on it. so what was the problem? Why is it doing it in v4 vs. older VS versions? Let me know when this fix is out since I am using whitelist. Thanks!

In reply to this comment by campionidelmondo:
Good news, I managed to fix the FlashBlock issue without having to disable automatic embed resizing I tested it in SeaMonkey 1.1.17 and the only little hiccup that seems to remain with the old version of FlashBlock is that you have to click the placeholder twice in order for the embed to show up. I hope you can live with that

Lucky still has to commit the new code, so it's not gonna work right away, but please let me know when/if it does, thanks

Wait. Wasn't it you who was having problems in Camino? I am using the latest FlashBlock version for SeaMonkey v1.1.17. I reproduced it at work and at home easily.


In reply to this comment by campionidelmondo:
Camino is MacOSX only, no? Afraid I couldn't use it then. However, the double-click bug has never been fixed from our end, because it is a bug in FlashBlock, which has been resolved in newer versions. If you're talking about having to double click on the FlashBlock placeholder, then the simple solution would be to upgrade.

In any case, nothing has changed in our code, so if it was working before the problem must be on your end.

In reply to this comment by ant:
Hmm. Are you seeing it in Camino?


In reply to this comment by campionidelmondo:
No, nothing changed.

In reply to this comment by ant:
Bad news. It is back again. Did you change something?

In reply to this comment by campionidelmondo:
Yes, it kinda is. Don't worry, it'll work for you using FlashBlock very soon

In reply to this comment by ant:
Interesting, and the resize is required?

In reply to this comment by campionidelmondo:
4.0 resizes the embeds via JS, which is neccessary because of the dynamic width the content div can have (it streches from 1024 to 1150px in fixed mode and to infinity in loose mode). v3.3 and older had static page widths, so the resizing was done server-side.

In reply to this comment by ant:
Hmm, double clicks? Keep working on it. so what was the problem? Why is it doing it in v4 vs. older VS versions? Let me know when this fix is out since I am using whitelist. Thanks!

In reply to this comment by campionidelmondo:
Good news, I managed to fix the FlashBlock issue without having to disable automatic embed resizing I tested it in SeaMonkey 1.1.17 and the only little hiccup that seems to remain with the old version of FlashBlock is that you have to click the placeholder twice in order for the embed to show up. I hope you can live with that

Lucky still has to commit the new code, so it's not gonna work right away, but please let me know when/if it does, thanks

Camino is MacOSX only, no? Afraid I couldn't use it then. However, the double-click bug has never been fixed from our end, because it is a bug in FlashBlock, which has been resolved in newer versions. If you're talking about having to double click on the FlashBlock placeholder, then the simple solution would be to upgrade.

In any case, nothing has changed in our code, so if it was working before the problem must be on your end.

In reply to this comment by ant:
Hmm. Are you seeing it in Camino?


In reply to this comment by campionidelmondo:
No, nothing changed.

In reply to this comment by ant:
Bad news. It is back again. Did you change something?

In reply to this comment by campionidelmondo:
Yes, it kinda is. Don't worry, it'll work for you using FlashBlock very soon

In reply to this comment by ant:
Interesting, and the resize is required?

In reply to this comment by campionidelmondo:
4.0 resizes the embeds via JS, which is neccessary because of the dynamic width the content div can have (it streches from 1024 to 1150px in fixed mode and to infinity in loose mode). v3.3 and older had static page widths, so the resizing was done server-side.

In reply to this comment by ant:
Hmm, double clicks? Keep working on it. so what was the problem? Why is it doing it in v4 vs. older VS versions? Let me know when this fix is out since I am using whitelist. Thanks!

In reply to this comment by campionidelmondo:
Good news, I managed to fix the FlashBlock issue without having to disable automatic embed resizing I tested it in SeaMonkey 1.1.17 and the only little hiccup that seems to remain with the old version of FlashBlock is that you have to click the placeholder twice in order for the embed to show up. I hope you can live with that

Lucky still has to commit the new code, so it's not gonna work right away, but please let me know when/if it does, thanks

Hmm. Are you seeing it in Camino?


In reply to this comment by campionidelmondo:
No, nothing changed.

In reply to this comment by ant:
Bad news. It is back again. Did you change something?

In reply to this comment by campionidelmondo:
Yes, it kinda is. Don't worry, it'll work for you using FlashBlock very soon

In reply to this comment by ant:
Interesting, and the resize is required?

In reply to this comment by campionidelmondo:
4.0 resizes the embeds via JS, which is neccessary because of the dynamic width the content div can have (it streches from 1024 to 1150px in fixed mode and to infinity in loose mode). v3.3 and older had static page widths, so the resizing was done server-side.

In reply to this comment by ant:
Hmm, double clicks? Keep working on it. so what was the problem? Why is it doing it in v4 vs. older VS versions? Let me know when this fix is out since I am using whitelist. Thanks!

In reply to this comment by campionidelmondo:
Good news, I managed to fix the FlashBlock issue without having to disable automatic embed resizing I tested it in SeaMonkey 1.1.17 and the only little hiccup that seems to remain with the old version of FlashBlock is that you have to click the placeholder twice in order for the embed to show up. I hope you can live with that

Lucky still has to commit the new code, so it's not gonna work right away, but please let me know when/if it does, thanks

No, nothing changed.

In reply to this comment by ant:
Bad news. It is back again. Did you change something?

In reply to this comment by campionidelmondo:
Yes, it kinda is. Don't worry, it'll work for you using FlashBlock very soon

In reply to this comment by ant:
Interesting, and the resize is required?

In reply to this comment by campionidelmondo:
4.0 resizes the embeds via JS, which is neccessary because of the dynamic width the content div can have (it streches from 1024 to 1150px in fixed mode and to infinity in loose mode). v3.3 and older had static page widths, so the resizing was done server-side.

In reply to this comment by ant:
Hmm, double clicks? Keep working on it. so what was the problem? Why is it doing it in v4 vs. older VS versions? Let me know when this fix is out since I am using whitelist. Thanks!

In reply to this comment by campionidelmondo:
Good news, I managed to fix the FlashBlock issue without having to disable automatic embed resizing I tested it in SeaMonkey 1.1.17 and the only little hiccup that seems to remain with the old version of FlashBlock is that you have to click the placeholder twice in order for the embed to show up. I hope you can live with that

Lucky still has to commit the new code, so it's not gonna work right away, but please let me know when/if it does, thanks

Bad news. It is back again. Did you change something?

In reply to this comment by campionidelmondo:
Yes, it kinda is. Don't worry, it'll work for you using FlashBlock very soon

In reply to this comment by ant:
Interesting, and the resize is required?

In reply to this comment by campionidelmondo:
4.0 resizes the embeds via JS, which is neccessary because of the dynamic width the content div can have (it streches from 1024 to 1150px in fixed mode and to infinity in loose mode). v3.3 and older had static page widths, so the resizing was done server-side.

In reply to this comment by ant:
Hmm, double clicks? Keep working on it. so what was the problem? Why is it doing it in v4 vs. older VS versions? Let me know when this fix is out since I am using whitelist. Thanks!

In reply to this comment by campionidelmondo:
Good news, I managed to fix the FlashBlock issue without having to disable automatic embed resizing I tested it in SeaMonkey 1.1.17 and the only little hiccup that seems to remain with the old version of FlashBlock is that you have to click the placeholder twice in order for the embed to show up. I hope you can live with that

Lucky still has to commit the new code, so it's not gonna work right away, but please let me know when/if it does, thanks

Its to bad Mr. O'Reilly, or either of the two blondes, go in to detail on exactly what *IS* the Commerce Clause of the US Constitution. The reason being, that those who watch Fox News and take it at face value (like republicans), won't look up what it is, nor challenge their idea of it.

They mention the Massachusetts health care system. As a resident, I can speak on experience of it. Its Wikked Kewl (that's boston for: its very good). Its set up to allow all citizens/residents (you have to be a US citizen to get it) access to health care coverage. If someone can not afford it, they are given it, based on several criteria. The criteria has nothing to do with one's race, wealth, education, or sex. Its actually based on both your use, and your current health. Those with cronic illinesses are given versions with more options, then someone who is in their 30's, and very healthy. That *is* how it should be done.

When the health care system (known as Mass Health) went in to effect, it said on the Mass Income tax form "If you do not have health insurance, you will pay a fine of $300". This was to encourage those who didnt have health coverage, to get Mass Health. Alot of people opt to pay the $300 and not have health coverage. So the state upped it to like $3400. But, as more people started getting it, more people have found the system mostly works. Yes, there are hiccups, and things that have to be disscussed, argued, and fixed in the system. But, this system for the most part, is working.

In addition, the health care system is very easy to budget. It makes up less then 1/3rd of 1% of next years budget (MA budget for 2010: $27 billion, Mass Health: $88 Million). And there is money set aside in what us Mass residents know as 'A Rainy Day Fund', so that if the health care unexpectantly rises up, there are funds to cover it temporarily. In addition, the health care companies in MA have no had an issue with this system. People get health insurance through their companies all the same. Private insurance can offer more options, including helping to pay for elective surgery (for example).

Besides the financial 'burden', Mass Health and other private insurance companies, have helped reduce the load on Mass hospitals. Its still pretty high, but the number is on a downward trend. The area is seeing inscreased bio / medical agencies and companies.

People like O'Reilly complain about Massachusetts health system. Folks, if we use this system nation wide, it would be an amazing thing for our country. Honestly, we get those Americans that do not have coverage, something to help. Since, suffering from disease and injury is already bad enough, without having to contemplate how you can afford the issue. Its a wise idea, for this country, and it will improve us as a nation.

OK and thanks.

In reply to this comment by lucky760:
It seems the problem returned because there was a hiccup with our servers. Do a hard reload again to insure you have the most current files and everything should be fine!

It seems the problem returned because there was a hiccup with our servers. Do a hard reload again to insure you have the most current files and everything should be fine!

Yeah, but double clicking sucks. Oh well.

In reply to this comment by campionidelmondo:
Yes, it kinda is. Don't worry, it'll work for you using FlashBlock very soon

In reply to this comment by ant:
Interesting, and the resize is required?

In reply to this comment by campionidelmondo:
4.0 resizes the embeds via JS, which is neccessary because of the dynamic width the content div can have (it streches from 1024 to 1150px in fixed mode and to infinity in loose mode). v3.3 and older had static page widths, so the resizing was done server-side.

In reply to this comment by ant:
Hmm, double clicks? Keep working on it. so what was the problem? Why is it doing it in v4 vs. older VS versions? Let me know when this fix is out since I am using whitelist. Thanks!

In reply to this comment by campionidelmondo:
Good news, I managed to fix the FlashBlock issue without having to disable automatic embed resizing I tested it in SeaMonkey 1.1.17 and the only little hiccup that seems to remain with the old version of FlashBlock is that you have to click the placeholder twice in order for the embed to show up. I hope you can live with that

Lucky still has to commit the new code, so it's not gonna work right away, but please let me know when/if it does, thanks