He predicted that a Keynesian economic policy would fail because it wasn't big enough? So if it fails it reinforces his views, and if it succeeds it reinforces his views. How can anybody be taken in by this?
If the doctor said you need to take 3 pills of antibiotics per day over the next week to clear up an infection and you instead take 3 on the first day, who was wrong if your infection isn't cured? Krugman has shown the work behind his predictions. If you have a more predictive model, the world would love to see it. If you just want to throw up your hands and say all models are BS, that's just denying the predictive utility of models.
The information on CDs may be digitally encoded, but the packaging (plastic disc, you know the "CD") is a physical thing. When you sell bits via a web site, there is clearly NOTHING physically significant that you are purchasing.
If the significance of the distinction isn't clear, consider that the text of books is every bit as digital as CDs. They might not be base-2 digits, but they are digits in some base none-the-less.
Yes, your computer will resend it. But it does even more! TCP interprets dropped packets as congestion and will reduce its load on the network, generally by 50%. Dropping more than one packet per round trip just serves to confuse TCP a bit more but the net effect is the same: reduce the load by 50%.
If the govt.just wants to create jobs, they can hire a million goons to destroy stuff and hire another million people to rebuild stuff - boom, 2 million jobs created. Thus you get Iraq, where we pay the military to break it and then turn around and pay contractors to rebuild it. Quite the stimulus package, although it seems less effective than spending US tax dollars in the US.
Maybe it's just our high quality politicians here in Oklahoma, but every time I see footage IED or car bombs in Iraq, I can't help but notice the roads over there, even with warfare going on, are in better shape than the roads here. Maybe it's the friendlier weather in the desert.
Re:Exit Polls are Inaccurate
on
Who won?
·
· Score: 1
Clearly I have more experience with computers than average (this is Slashdot), but I don't see how a computerized system is any more complicated than filling in those annoying bubbles or operating some Baroque lever pulling machine.
Clearly you have less experience with computers than you think. Microsoft alone has found nearly infinite ways to make simple things hard, and they've actually improved their act a bunch in recent years through user interface testing. Somehow, I doubt the electronic voting machine vendors spent much more time on user interface refinement than they did on security. Seeing as they completely blew the latter, little issues like touch screens that don't seem to know just where they're being touched or negative vote totals are practically inevitable.
The real problem with this idea comes in with people who want access from rural locations or connecting cities across large distances. Who is going to pay the million bucks to get the wiring from the DFW area to Austin?
As to the inter-city hauls, those are already available at decent rates once you get your local bits to a nearby POP.
Sayeth the Cringe (I RTFA):
Of course you'd still have to buy Internet service, but at NerdTV rates the amount of bandwidth used by a median U.S. broadband customer would be less than $2.00 per month.
The whole point of the article is that by doing the expensive (relative to a consumers monthly ISP bill) last mile infrastructure ourselves, we avoid the rent seeking behaviors of the current last mile owners who are more in the business of monthly billing events than transporting packets. If you pay $50 a month for broadband and the part of that service between your local POP and the rest of the world currently runs about $2 per month, what exactly do you get for that other $48 per month? Email service? Blocked server ports? The ability to get a less comprimised QoS by paying more?
Cringe thinks we could, over a 10 year period, finance fiber to your door with crazy local bandwdith (basically free) and cheap metered Internet service (for what you use today, not necessarily what you might use when you can do BitTorrent at 100Mbit/s symetrical) for about $20 per month if you and your neighbors worked collectively. At that point, ISPs and TV providers would be more likely to beat a path to your "last mile" door since the really really expensive part was already built by someone else (you) who doesn't discriminate against them like the Bells would against CLECs.
The plane is usually constructed with a skin of aluminum that conducts quite nicely, so the lightning heads on out the other side of the plane. The static wicks are more for avoiding problems with radio communications and navigation equipment.
So you've basically proven nothing, except help reinforce the notion that cookies are the most reliable and practical method for passing a session id back and forth.
I would argue that embedding a session ID in the URL is more reliable. I actively use multiple browsers for the same task and am often annoyed when a web site gets confused by my dropping a URL/link from one browser onto another. (Why would I want to do that? Well, my copy of Safari renders gorgeous text but sometime for bulk viewing I prefer to drop things into Mozilla tabs. Sometimes I use a third browser that deals better with progressive JPEGs. [Mozzila seems to wait for the whole file before showing anything.])
Cookies are often convenient but only because server side programming tools are so often inconvenient. By focusing on responses as text or byte streams, you too-easily prevent the ability to do things like rewriting URLs quickly and efficiently without much extra effort. With appropriate code support, rewriting URLs should be no harder or more inefficent than bulk file transfers. (Hint: parsing the text streams character by character to find URLs is not the easy way).
I once worked on a commercial web site where full URLs were embedded in web pages because multiple application servers sat behind a half-standalone/half-proxy web server and the (incovenient) mechanism used to pass HTTP requests to the backends (some JRun, some WebLogic, and some specialized vertical application web servers) couldn't automatically understand what they user-visible web server name should be and would otherwise put stuff in the URL that broke links from one backend server to another. Ick. If the app servers made URL rewriting convenient, we wouldn't have had to invent extra hacks that interposed logic between the proxying front end and various backends to deal with the several sessions that, to the end user, had to appear as a single session
Other possible alternatives not listed above include
SSL session data to track a session
using per-session dynamic DNS for server with Host header decoding (not a good idea if using SSL)
extend HTTP to allow keep a connection alive until the session it represents ends (thus fixing the original break that sent everyone scrambling to cobble together hacks to come up with a session that didn't bust because connections weren't congruent with sessions
Please don't complain that these don't work with existing browsers in the real world. Cookies didn't work, either, until they were widely supported. Please don't require cookies unless there's a really good reason to. If you can generate dynamic HTML just for me (ala Amazon, where you won't be caching things Amazon thinks I might also be interested based on my last N searches in that session to show to others not associated with Ashcroft) you can write your URLs in a way that encodes the notion of a session. If this would break your notion of security, you security is already broken.
Of course, if the head isn't sitting on the track and reading data into its buffers before the desired sector passes by, any request for the preceding sectors will require another rotational delay.
How useful that is in practice would vary widely, I suspect.
In my eyes, all these incredibly obvious software patents have the same pattern:
Take a simple, obvious, widely deployed idea (such as ordering with one query)
Mix some combination of "computer", "network", "automatic"
Pat self on back for contribution to the so-called state of the art.
Release the hounds..errr.. licensing and infringement laywers.
The truly frightening part is that mixing in computers and/or networks seems to make the obvious somehow insightful. As for One Click Ordering, am I doing something different when I call a supplier with whom I have an established relationship ship?
me "Hi, this is Bob at Widgets Are Us, I need two gross by Thursday. That's all." widget wholesale "Two gross widgets are on their way."
I've never thought twice about ordering from suppliers by leaving a voice mail message with nothing more than my ID (usually my name and company) and a product ID (often a code from a catalog). Take this simple, common practice and add in a computer and suddenly it is somehow non-obvious to an examiner. Or at least the PTO thinks so.
The scary part is realizing the shift to the information age along with this patent recipe is like granting patents during the industrial revolution for "a machine that [insert useful task here]" and not requiring anything novel about either the machine or the task.
I think the test for nonobviousness should place the idea in front of a group of reasonbly intelligent programmers and have them invent a apparatus/method/process. If the programmers find no difficulty in "inventing" means to implement the idea, then it should be rejected sumarrily. If the applicant wanted to limit the scope by detailing a particular implementation that was non-obvious, perhaps that might be patentable. At least then the rest of us could "invent" one of innumerable equivalent mechanisms.
Our only hope is that the PTO does such a thoroughly bad job with poor patents that high dollared companies begin to consider the PTO a liability rather than an affordable weapon of commerce.
I don't think it is necessary that everyone deeply understand all the parts of a non-small, complex system they are building. However, I've had occasion to work on several moderate to large projects (5 to 30 developers and dozens more testers, business requirements analysts, etc, usually interfacing with several other "island" systems so big and complex you can't understand them and have to rely on expert representatives for guidance) that started out with compartmentalized development.
Some sort of high level design was created and individual developers where sent out to write small pieces (typically smallish C++ database applications) that were supposed to all work together to complete the big grand scheme.
Usually the individuals end up working in a vacuum. Worst case is "grab records from here, do this logic, put results over here, and quit asking how it really works, just trust the design." Meanwhile, the business/Big Picture implications of "do this/do that" are not apparent to the individual coders. Meanwhile, the brutal reality is the Big Picture was just a sketch. It's not until integration time (hopefully) that you find some combination of coders making assumptions inconsistent with the Big Picture and instances where the Big Picture left out important cases. If the missing cases don't fall neatly in an individual coder's sandbox, then the problems sometimes see the light of production.
Once your screw up is in production and supposedly firm deadlines are "succesfully" passed, you get to sit with all the other developers and tiger team solutions to all those broken assumptions that under production usage manage to blossom into failure, usually outside the scope of any one developer's code. This sometimes involves debugging complex interactions where you start to question whether any one system, be it database server, access library, widely-published-and-respected class library, aren't actually failing somewhere. Having several eyeballs and hypothesis generators can track down a problem with super-linear scaling up to about 5 people. (You also get to find which software vendors put out products that need more debugging than your own code.)
In this "what went wrong?" phase, you finally learn how the system was supposed to work (the Big Picture), how it really works as coded, and what the Big Picture should have been. A small group of sharp developers can then brainstorm lots of ways to correct the problems, sometimes with ugly hacks, sometimes architectural modifications, and the occasional elegantly simple fixe.
So long as the Big Picture's original authors aren't hung up on their (incomplete, buggy) plan being implemented as they dreamed it, you end with a much better, robust design. Unfortunately, you may have to also figure out how to (1) implement that design into a live system with as small an outage as you can afford and (2) clean up the data the wacky first release thoroughly messed up, often using throw-away code you'll only run once in production. With luck, your "really important" system wasn't as important as you were lead to believe.
If we could have just gotten everyone together to let the developers in on the big picture, we would have been much better off with the first release. Understanding the Big Picture implications of what your code does is critical to the end result working well, especially when the test cases developed aren't capable of probing beyond the edges of design in the same way that real life users and unexpected derailments and failures can.
Users in my organisation have come to expect any first implementation of a project to be a rough draft that will be transformed into something actually usable Very Quickly within a few weeks of release.
Slashdot Mirror
He predicted that a Keynesian economic policy would fail because it wasn't big enough? So if it fails it reinforces his views, and if it succeeds it reinforces his views. How can anybody be taken in by this?
If the doctor said you need to take 3 pills of antibiotics per day over the next week to clear up an infection and you instead take 3 on the first day, who was wrong if your infection isn't cured? Krugman has shown the work behind his predictions. If you have a more predictive model, the world would love to see it. If you just want to throw up your hands and say all models are BS, that's just denying the predictive utility of models.
The information on CDs may be digitally encoded, but the packaging (plastic disc, you know the "CD") is a physical thing. When you sell bits via a web site, there is clearly NOTHING physically significant that you are purchasing.
If the significance of the distinction isn't clear, consider that the text of books is every bit as digital as CDs. They might not be base-2 digits, but they are digits in some base none-the-less.
Yes, your computer will resend it. But it does even more! TCP interprets dropped packets as congestion and will reduce its load on the network, generally by 50%. Dropping more than one packet per round trip just serves to confuse TCP a bit more but the net effect is the same: reduce the load by 50%.
Maybe it's just our high quality politicians here in Oklahoma, but every time I see footage IED or car bombs in Iraq, I can't help but notice the roads over there, even with warfare going on, are in better shape than the roads here. Maybe it's the friendlier weather in the desert.
As to the inter-city hauls, those are already available at decent rates once you get your local bits to a nearby POP.
Sayeth the Cringe (I RTFA):
The whole point of the article is that by doing the expensive (relative to a consumers monthly ISP bill) last mile infrastructure ourselves, we avoid the rent seeking behaviors of the current last mile owners who are more in the business of monthly billing events than transporting packets. If you pay $50 a month for broadband and the part of that service between your local POP and the rest of the world currently runs about $2 per month, what exactly do you get for that other $48 per month? Email service? Blocked server ports? The ability to get a less comprimised QoS by paying more?
Cringe thinks we could, over a 10 year period, finance fiber to your door with crazy local bandwdith (basically free) and cheap metered Internet service (for what you use today, not necessarily what you might use when you can do BitTorrent at 100Mbit/s symetrical) for about $20 per month if you and your neighbors worked collectively. At that point, ISPs and TV providers would be more likely to beat a path to your "last mile" door since the really really expensive part was already built by someone else (you) who doesn't discriminate against them like the Bells would against CLECs.
The plane is usually constructed with a skin of aluminum that conducts quite nicely, so the lightning heads on out the other side of the plane. The static wicks are more for avoiding problems with radio communications and navigation equipment.
I would argue that embedding a session ID in the URL is more reliable. I actively use multiple browsers for the same task and am often annoyed when a web site gets confused by my dropping a URL/link from one browser onto another. (Why would I want to do that? Well, my copy of Safari renders gorgeous text but sometime for bulk viewing I prefer to drop things into Mozilla tabs. Sometimes I use a third browser that deals better with progressive JPEGs. [Mozzila seems to wait for the whole file before showing anything.])
Cookies are often convenient but only because server side programming tools are so often inconvenient. By focusing on responses as text or byte streams, you too-easily prevent the ability to do things like rewriting URLs quickly and efficiently without much extra effort. With appropriate code support, rewriting URLs should be no harder or more inefficent than bulk file transfers. (Hint: parsing the text streams character by character to find URLs is not the easy way).
I once worked on a commercial web site where full URLs were embedded in web pages because multiple application servers sat behind a half-standalone/half-proxy web server and the (incovenient) mechanism used to pass HTTP requests to the backends (some JRun, some WebLogic, and some specialized vertical application web servers) couldn't automatically understand what they user-visible web server name should be and would otherwise put stuff in the URL that broke links from one backend server to another. Ick. If the app servers made URL rewriting convenient, we wouldn't have had to invent extra hacks that interposed logic between the proxying front end and various backends to deal with the several sessions that, to the end user, had to appear as a single session
Other possible alternatives not listed above include
Please don't complain that these don't work with existing browsers in the real world. Cookies didn't work, either, until they were widely supported. Please don't require cookies unless there's a really good reason to. If you can generate dynamic HTML just for me (ala Amazon, where you won't be caching things Amazon thinks I might also be interested based on my last N searches in that session to show to others not associated with Ashcroft) you can write your URLs in a way that encodes the notion of a session. If this would break your notion of security, you security is already broken.
How useful that is in practice would vary widely, I suspect.
Take a simple, obvious, widely deployed idea (such as ordering with one query)
Mix some combination of "computer", "network", "automatic"
Pat self on back for contribution to the so-called state of the art.
Release the hounds ..errr.. licensing and infringement laywers.
The truly frightening part is that mixing in computers and/or networks seems to make the obvious somehow insightful. As for One Click Ordering, am I doing something different when I call a supplier with whom I have an established relationship ship?
me "Hi, this is Bob at Widgets Are Us, I need two gross by Thursday. That's all."
widget wholesale "Two gross widgets are on their way."
I've never thought twice about ordering from suppliers by leaving a voice mail message with nothing more than my ID (usually my name and company) and a product ID (often a code from a catalog). Take this simple, common practice and add in a computer and suddenly it is somehow non-obvious to an examiner. Or at least the PTO thinks so.
The scary part is realizing the shift to the information age along with this patent recipe is like granting patents during the industrial revolution for "a machine that [insert useful task here]" and not requiring anything novel about either the machine or the task.
I think the test for nonobviousness should place the idea in front of a group of reasonbly intelligent programmers and have them invent a apparatus/method/process. If the programmers find no difficulty in "inventing" means to implement the idea, then it should be rejected sumarrily. If the applicant wanted to limit the scope by detailing a particular implementation that was non-obvious, perhaps that might be patentable. At least then the rest of us could "invent" one of innumerable equivalent mechanisms.
Our only hope is that the PTO does such a thoroughly bad job with poor patents that high dollared companies begin to consider the PTO a liability rather than an affordable weapon of commerce.
Some sort of high level design was created and individual developers where sent out to write small pieces (typically smallish C++ database applications) that were supposed to all work together to complete the big grand scheme.
Usually the individuals end up working in a vacuum. Worst case is "grab records from here, do this logic, put results over here, and quit asking how it really works, just trust the design." Meanwhile, the business/Big Picture implications of "do this/do that" are not apparent to the individual coders. Meanwhile, the brutal reality is the Big Picture was just a sketch. It's not until integration time (hopefully) that you find some combination of coders making assumptions inconsistent with the Big Picture and instances where the Big Picture left out important cases. If the missing cases don't fall neatly in an individual coder's sandbox, then the problems sometimes see the light of production.
Once your screw up is in production and supposedly firm deadlines are "succesfully" passed, you get to sit with all the other developers and tiger team solutions to all those broken assumptions that under production usage manage to blossom into failure, usually outside the scope of any one developer's code. This sometimes involves debugging complex interactions where you start to question whether any one system, be it database server, access library, widely-published-and-respected class library, aren't actually failing somewhere. Having several eyeballs and hypothesis generators can track down a problem with super-linear scaling up to about 5 people. (You also get to find which software vendors put out products that need more debugging than your own code.)
In this "what went wrong?" phase, you finally learn how the system was supposed to work (the Big Picture), how it really works as coded, and what the Big Picture should have been. A small group of sharp developers can then brainstorm lots of ways to correct the problems, sometimes with ugly hacks, sometimes architectural modifications, and the occasional elegantly simple fixe.
So long as the Big Picture's original authors aren't hung up on their (incomplete, buggy) plan being implemented as they dreamed it, you end with a much better, robust design. Unfortunately, you may have to also figure out how to (1) implement that design into a live system with as small an outage as you can afford and (2) clean up the data the wacky first release thoroughly messed up, often using throw-away code you'll only run once in production. With luck, your "really important" system wasn't as important as you were lead to believe.
If we could have just gotten everyone together to let the developers in on the big picture, we would have been much better off with the first release. Understanding the Big Picture implications of what your code does is critical to the end result working well, especially when the test cases developed aren't capable of probing beyond the edges of design in the same way that real life users and unexpected derailments and failures can.
Users in my organisation have come to expect any first implementation of a project to be a rough draft that will be transformed into something actually usable Very Quickly within a few weeks of release.