There's this funny little hyperbolic-looking curve called the Phillips Curve, which ties inflation to unemployment. If you even tried to push one to zero, the other rises sky-high.
That's not actually what the Phillips Curve says. It's not a relation between current inflation and current unemployment but a relation between current unemployment and inflation from then. In other words, you can reduce unemployment right now by increasing inflation forever. Conversely, you can decrease the permanent inflation rate by increasing unemployment temporarily (see the 1981 recession in the US for an example).
It's relatively obvious that it's stupid to trade a temporary improvement for a permanent negative. Particularly since high enough levels of inflation feed back and cause higher levels of unemployment (see the 1970s in the US).
The Phillips Curve is not a limit on inflation or unemployment in the long term (or even the medium term). It's simply a description of the impact of certain decisions in the short term. In the medium term, unemployment results from structural issues in the economy. Inducing inflation to hide from unemployment just shifts the unemployment later and deeper.
I had a Cisco 400 with a lifetime warranty. It died a while back. It was out of warranty. Apparently Lifetime for Cisco means 5 years.
While lifetime sounds like it should be your life time, it actually refers to the product life time. In other words, some time after they stop manufacturing the product, it's lifetime is considered over (you're expected to upgrade at that point). "Some time" is usually something like one to three years. Your warranty probably defines "some time" in the pages of legalese.
I used to be able to find internet documentation of this relatively easily, but today it was harder. I did still find http://www.directron.com/warranty-policy.html which says, "Lifetime is defined as the lifetime of the product on the market. Outdated technology is not covered by lifetime warranty if the item is no longer available on the common market as a new product."
cranes, welders, plasma tables, galvinization equipment, etc. that is required for us to build our product isn't just going to magically take less electricity just because we want it to.
The idea is that the controls will move from ad hoc human decisions (e.g. I'll flip on the welder now because I plan to use it in five minutes) to computer planned decisions (where work is scheduled for the welder so as to minimize the amount of time when the welder is warming up, etc.). The example given in the article is heating and cooling. For example, if you know that it will be hot during the day and cold at night, you can allow the temperature to gradually increase during the day and cool overnight if you only have a daylight shift.
Of course, we've been talking about doing this for twenty years. While this is the future, I don't know that it is particularly likely to take over in the next few years. It will gradually become more common, the way that it is now common for every automobile to have computer controlled fuel injection, valves, and sparking system rather than operate purely mechanically.
They are just elective, as they should be. But any kid wanting to learn comparative religion can do so.
There was no religion class in my public high school. I doubt that my high school was unique in that regard. I'm sure that your high school was not unique in offering them either, but saying that "any" kid can take comparative religion is just plain incorrect.
At some point the value of having exclusive functionality exceeds the merge costs, depending on a boatload of factors ranging from interface complexity and stability, business value, use by competitors, specificness of the issue solved and so on.
In the short term, that can certainly be true. However, what happens when you merge it for the fourth, tenth, etc. time? Especially as the merge tends to get more difficult over time. Also, note that the more work it is to add the functionality, then the more work it is to merge the functionality.
Another issue is that if the functionality is actually useful to someone else, someone will probably eventually upload it to the project in some form. If your company does this, then your upgrade path is usually pretty clear. If someone else does this, then the upgrade path can be far more difficult. Merging will also be more difficult (you may need to rip out functionality before adding your own).
Conversely, if your company is first to upload and your competitors need to migrate from their platform to your platform, that's often as much work as writing their own solution. In the long term, both of you will be better off, as you'll save on maintenance. In the short term, their migration is likely to cost enough that you don't lose by offering them your software.
There may be circumstances where it's better to hold your changes private, but those are going to be rare. Two competitors both using the same open source software as base but only one having implemented a particular feature. Said feature being relatively isolated from the rest of the codebase (such that there is little interaction that will be costly to merge). The feature being highly important to the business. Maybe. But event then, what happens if the competitor without the feature adds it? Then the first company has to either port their version or keep maintaining their version.
Also, the FDIC is slowly but surely ruining our financial economy. Why do you think lenders gave out so many subprime loans? Because the owners know that whatever happens, they are personally immune. Why do people no longer care to ensure that the S&L's they put their money in are financially sound? Because they know that they are immune,
This is why we should have full reserve banking (or at least increase reserves from 15% to 50%). Banks are over funded and loan out too much money. FDIC insurance should be limited to a $100,000 per person, not a $100,000 per bank account.
The truly ridiculous thing about the subprime mess is that it wasn't the mortgages themselves that caught the banks. Instead, it was the loans to the companies that bought the mortgages. In what way does it make sense to loan out money to buy something that is essentially a stock? The whole point of a stock is to allow people to risk the whole investment. Further, the whole point of securitizing the mortgage in the first place was to get the banks out of that risk. Why step back in by loaning money against the mortgage?
Someone has blown the whistle and turned on the flashing yellow klaxons to alert Virginia citizens and lawmakers to shoddy privacy practices. She's not trying to profit, she's probably not even trying to benefit from this work (except, perhaps in a very professional way).
Even better. There is a simple way for any municipality to get the information taken down from her site. All they have to do is stop displaying it publicly, let her know, and she removes the data. Ten of the municipalities listed have already done that. Of course, there are still eleven more that have not (including those with data for Jeb Bush in Florida and Colin Powell).
Her claim seems to be simple. If it's publicly posted on the internet, then it's not private and she can post it on her web site.
I'm not sure that I entirely agree with her thesis though. She seems to be saying that it's all right for this data to be public, just so long as it's not online. Personally, I don't think that any of this is data that needs to be public. The online part just makes it easier to access. In some ways, it would actually be easier to hide this data online (and limit access to the original physical records with the complete data). Then all the public data could be online and that part that is private (e.g. SSNs) would only be available to those few people that have real need to see the actual physical documents.
Sure, Google could aggregate the data and use it. Are they? They say they aren't yet. They may do so in the future. If they do, it won't replace the algorithm, it will just be added as an extra input.
Google sometimes tracks on what links users click in search results. They could use that data to reorder search results. If they do, is that using your brain to do work?
Google works by analyzing links around the web. These links are the results of people's decisions. Is that using your brain to do work?
Google says that they use the Google Image Labeler (GIL) data to improve image search results. There's no secret about it. The point is that there is no way currently to programmatically analyze a picture and come up with what it shows. Google created a system that collects human input.
By contrast, this system is wholly inappropriate for collecting that data. In GIL, they randomly assign images; in this, you choose the search. In GIL, they randomly assign you a partner; in the system you describe, they would be using the entire crowd. The problem here is that the system that you describe would be easy to game. With GIL, you would have to both be randomly assigned an image that matters to you and be randomly assigned a partner who also wants to corrupt the results. With the system that you propose, the people with the most incentive to use the system are those who want to game the results.
I think that you are underestimating the amount of analysis that would be needed to make use of this data. Ignoring the fraud problem for the moment, even if you only use the data from legitimate users, what would the data mean? If I label a search result "Jacques", does that mean that someone named Jacques appears in the result? That I think that someone named Jacques should appear in the result? That I think that someone named Jacques would be interested in the result? That I know a golden retriever named Jacques and this link is about golden retrievers? For the first of those possibilities (admittedly the most likely), this search result should appear when people search for Jacques. For the second, it should not appear and should be downgraded in the current search term (how could they forget Jacques!). For the third, perhaps it should be upgraded for the current search term. If you can find useful information in the fourth...
Sure, but who has requirements that match MS Office exactly? With MS Office, if it does not match perfectly, you have to change your procedures to match the software. With OpenOffice, you could do that or you could change the software to match what you actually want to do.
It's also worth noting that there is nothing in the article or the press release about either office suite. The primary software to which they are referring is the operating system. With the operating system, the issue is generally that it is easier to configure a single MS Windows desktop than a single Linux desktop, so they go with MS Windows. However, if they spent the licensing money on support instead, they could get someone to configure the Linux desktops and still have left over budget to do customizations to better support their procedures.
They're also arguing that the people from whom they would buy the support would be local, while MS Windows is written in Redmond, India, etc. That argument doesn't hold much sway with me. If they are buying the software with Canadian dollars, then the only place to spend the Canadian dollars is in Canada. One way or the other the money will get spent in Canada, creating Canadian jobs. Perhaps not computer jobs because Canada may be more efficient at something else (e.g. providing weekend getaways in Vancouver for stressed out Microsoft employees from Redmond), but some kind of job.
Google has thus far always held that the only way to deal with this problem is automation, I find it really interesting to see them turn around like this and yield to the 'wisdom of the crowds'.
Crowds aren't involved at this point. All this does is allow an individual to change the ordering of search results on a page and add comments. Presumably the individual could come back to the same search later and see the same results, but there's nothing in the description of the experiment that suggests that anyone else would see this.
In the future, they might incorporate this as an additional input in their ranking algorithm, but at the moment, it's just for personal use.
The assumption in this case is that you already went through the low level area once. You are now returning to the area that you already beat purely because you need more experience points. It wasn't meaningless the first time; it's meaningless to repeat it once you've become sufficient powerful to make it easy to beat.
I think that you are looking at two different things:
Feanturi: being able to arbitrarily go to any place in the game and be competitive makes it hard to have a progressive and coherent story. This leads to boring games without good story lines.
Doctor_Jest: having the difficulty for a place in the game be such that you need to be level X to play it forces you into meaningless activities purely to gain levels. This is boring.
It's at least conceivable that one could address both concerns in the same game. Have scaling, but also have dependencies for various missions. If you haven't completed the dependencies for a mission, then the scaling should be set high (and NPCs should warn you away from that area and point you back where you should be).
It seems to me that Diablo II did that by simply prohibiting you from certain areas until you had completed the prior missions. However, the Diablo II scaling for necromancers was bad for me, as I got stuck needing a Blood Golem (IIRC) to defeat Andariel. This led me to grind for a while to get up to the necessary level.
Playing the game in story order (possibly with some side missions that are optional) while always being tough enough to be challenging but not so tough to be impossible makes for a more fun gaming experience. Making that happen with as few limits on gameplay as possible is difficult but should not be impossible.
The license under which you release your code is irrelevant with regards to patent law.
The difference is that the company holding the patent can't distribute the code under the GPL. Consider the case where you write code; someone else patents part of the basis for your code; now they redistribute the code that you wrote and charge their patent rent. With GPLed code, they couldn't redistribute your code (they'd have to write their own).
Sure, but correlation is not causation. Let's assume that Iowa were not handing out tax breaks. What might happen instead? It's quite possible that the server farms would still go there (it's centrally located, cheap power, and low wages). Then they'd have all the current benefits plus higher tax revenues.
You can only measure results if you know what would happen without intervention. Without that, all that you are measuring is current state. You don't know if the current state is because of your change or despite it.
What is really needed is a secure version of DNS. It should be the site telling me that it is high security. This would cover both online banking (high security needed, in particular, verification of identity) and the personal router case (lower security).
Under the current system of DNS, my computer talks to my DNS server, which then goes to the root server, then it goes to the domain server. Since those connnections are plain UDP, they are easily subject to Man in the Middle attacks.
In a secure DNS system, my DNS server would have to supply credentials to establish identity and it would check credentials of its source servers. Then, when I request an online banking domain, part of the return information could be that only https is allowed and another part could provide a validation key. Then, when I get the certificate, I apply the validation key to verify the certificate. If the validation key fails, Firefox gives the current error and won't let you continue without jumping through serious hoops (or perhaps not at all).
Since we don't have a secure DNS, we can't do this, as it's currently too easy to provide false DNS results. With a secure DNS, we could do away with Verisign, et.al. in favor of DNS provider verification. Further, we would close all the other holes caused by having only insecure DNS.
The part that you're missing is that neither party is a cop in this. The point of entrapment is that the law officials can be really aggressive about getting the other person involved, after all, they aren't going to be prosecuted. Further, it's quite possible that the crime would not occur at all without the actions of law enforcement.
This isn't between your two situations; it's on an entirely different line. A better way of thinking about this is "What if it wasn't a scam?" If there really was a Nigerian trying to smuggle money out of the country, could you prosecute the other participant? If so, then the fact that it is a scam in this case is irrelevant. The victim would have acted in the same way if it had been real (to them it was).
The downside to prosecuting the victim is that it would lead to less victims coming forth. This would be clearly to the benefit of the Nigerian official (who has to do work when a scam is reported). However, it would make it less likely that the scammers on the Nigerian side would get caught. Thus, future victims would be more likely.
I would propose the following compromise. Victims who come forward on their own, don't get prosecuted. However, if the Nigerians discover additional victims when they arrest the scammers, those people should get prosecuted (especially if they don't realize that they have been victimized yet).
http://www.psychocats.net/ubuntu/graphicalsudo also points out that sudo often preserves the original users environment. As a result, running it with an application with a configuration file (very common for GUI apps) can cause the configuration file to end up owned by root (particularly if you run it under sudo before running it as a normal user).
Mozilla would have an easier time suing over 'Foxfire' if it is an internet browser than Microsoft had in suing someone for naming their product 'Lindows'. Neither fox nor fire has anything to do with internet browsing. As such, it is a defensible trademark in the internet browsing arena. It would not be defensible if the competing product actually involved setting flame to that breed of canid, as it would be generic then (in the same way that it was ruled that windows was a generic term in the US computing market).
She cites the case of someone who is upset at reading the divorce case of her parents.
Well, here's something: don't read it!
I think that the child reading it directly is less of an issue than having it come from someone else. E.g., I hear your dad doesn't love you (based on the mother's statement in the divorce case) or that your mom boinked the butcher.
It's also worth noting that children of divorcing parents are often depressed, and depressed people do things that are bad for them. It may not be the child who is concerned about being upset. It may be the parent who is concerned about the child being upset.
But even aside from the issue of functionality vs. security, there's the issue of security somehow being way more important in the browser, which I think is nonsense. Client-server apps have always had lousy security, and were easily hijacked. Just because they now run in a browser, the threat level hasn't changed. A hacker that is determined can break in sure, but they've always been able to break in. Nothing has truly changed, except for the perception of the threat level.
There are reasons why browsers are different from other client/server applications:
Browsers are a generic application platform that can be used to run other applications.
Browsers often run all current applications in the same sandbox. This allows an insecure news reader (not so important in itself) to lead to compromise of your banking connection.
Browsers are being used to run desktop applications (think Google Docs).
Part of the point of HTML5 is to make it easier to do things like implement a desktop application in the browser. As such, the comparison with the security of client/server applications is not appropriate. It's the equivalent desktop application's security that should be the goal.
It's also worth noting that the easiest time to add security is at the beginning. Once applications have been written to a certain model, it's expensive to change the model. Now, when there are no HTML5 applications, is the best time to make their security model robust.
The notion that people counting votes by hand is somehow always more accurate than a machine counted vote is ludicrous to me.
It's not more accurate; it's more verifiable. On average, even with some rather large machine errors, machines still probably have a lower error rate than hand counting. However, with the machine, you can count once and only once. If that's wrong the first time, it will still be wrong the second time. Machines act predictably on input. With paper ballots, you can go back to the original source of the data.
That said, it's perfectly possible to make a system that has all the advantages of the machine count but still have a verifiable, human-readable paper trail. You can't do that with these machines, because they weren't made that way.
How would such a machine work? The easiest way would be to simply print out the ballot; the voter reads it and verifies that they voted for Al Gore and not Pat Buchanan (the problem with the Florida ballots in 2000); the voter drops the printed ballot in the ballot box. If the ballot is incorrect, the voter puts the ballot back in the voting machine and redoes it. If it's still wrong, the voter escalates to an election official for further assistance.
It's worth noting that an optically scanned system can do the same thing. The important part is that the voter be able to see how the machine scores the ballot. A common problem in Florida was where two or more holes were punched. The voter should have redone the ballot in that case. If they had run it through a scoring system that told them that the ballot would not have counted their votes correctly, then presumably they would have done so. A side effect of that is that by adding up all the verification votes, you have an instant score. You only need to recount the ballots in an actual recount.
maybe what we need is a more verbose regex syntax.
What's really ironic about that statement is that Perl's RegEx syntax is actually one of the best parts of it. If you use/x, you can comment your RegEx and spread it over multiple lines. If you switch from the original// notation to {} notation, you can make it more readable (particularly when you need to use/s in your RegEx). Further, Perl supports embedding RegExes in other RegExes, e.g.
my $ALPHA = qr{[A-Za-z]}xsm; my $NUMERIC = qr{[0-9]}xsm; my $ALPHANUMERIC = qr{$ALPHA|$NUMERIC}xsm; my $VALID_USER_ID = qr{$ALPHA $ALPHANUMERIC*}xsm;
if ( $user_field =~ m{$VALID_USER_ID}xsm ) {
# do something } else {
# handle error case }
(my syntax may be slightly off, I'm writing without a perl interpreter). In any case, the point I was making was that you can write self documenting Perl RegExes now. The problem is that you can also write horribly obfuscated RegExes.
The problem isn't that it is impossible to write elegant, maintainable code in Perl. It's that there are so many bad ways to write Perl code, chances are that at least one programmer who has worked on the script has done so. Especially since Perl maintains backward compatibility with all the stupid ways that things were done previously, which makes it hard for the interpreter to determine at compile time if something is stupid. It needs the run time context.
This isn't unique to Perl. I have the same problem with (the JAVA ORM) Hibernate's inability to tell me that I misspelled a column reference in my HQL until it fails catastrophically at run time (and its inability then to tell me which column reference is broken). This leads to a large number of Hibernate unit tests that basically implement compiler warnings by exercising code. However, it is very common in Perl.
IMO, it's not that Perl has passed its time. It's just that the language is not really intended for the purposes to which it is being put. It's not a highly maintainable language for user facing code. It's a system administrator language with its scripts intended to be run by the author of the script.
I'd pay for a new Battle for Wesnoth campaign. I'd love to see a bazaar arise, where multiple organizations provide images and story ideas, while all working on the same backend.
I doubt it'd work as well away from big lakes, or in areas where the ground leaks too much.
You don't need an existing lake. You can build one if necessary. Further, you can build both reservoirs out of materials that don't leak. I would think that the bigger problem is that you need the two reservoirs to be separated in height. I.e. you need hills. Meanwhile, many of the best places for wind generation are flat. Lakes are cheaper to build than mountains. Further, the reservoirs can be used as a water supply during droughts, etc.
You may also need this kind of stuff for nuclear. The problem is that nuclear produces a relatively steady stream of power, while usage is bursty. Thus, use of natural gas and oil to provide on demand source to balance supply to demand. However, if we go with Pickens plan, we will stop using oil for this, and move the natural gas to use in powering automobiles. There are some biofuel alternatives (in particular, using landfill gas or other waste based generation works nicely with electrical generation), but it may be that this will not be enough.
Slashdot Mirror
There's this funny little hyperbolic-looking curve called the Phillips Curve, which ties inflation to unemployment. If you even tried to push one to zero, the other rises sky-high.
That's not actually what the Phillips Curve says. It's not a relation between current inflation and current unemployment but a relation between current unemployment and inflation from then. In other words, you can reduce unemployment right now by increasing inflation forever. Conversely, you can decrease the permanent inflation rate by increasing unemployment temporarily (see the 1981 recession in the US for an example).
It's relatively obvious that it's stupid to trade a temporary improvement for a permanent negative. Particularly since high enough levels of inflation feed back and cause higher levels of unemployment (see the 1970s in the US).
The Phillips Curve is not a limit on inflation or unemployment in the long term (or even the medium term). It's simply a description of the impact of certain decisions in the short term. In the medium term, unemployment results from structural issues in the economy. Inducing inflation to hide from unemployment just shifts the unemployment later and deeper.
I had a Cisco 400 with a lifetime warranty. It died a while back. It was out of warranty. Apparently Lifetime for Cisco means 5 years.
While lifetime sounds like it should be your life time, it actually refers to the product life time. In other words, some time after they stop manufacturing the product, it's lifetime is considered over (you're expected to upgrade at that point). "Some time" is usually something like one to three years. Your warranty probably defines "some time" in the pages of legalese.
Yep, here's the Cisco warranty: http://www.cisco.com/en/US/docs/general/warranty/English/LH2DEN__.html which says, "In the event of discontinuance of product manufacture, Cisco warranty support is limited to five (5) years from the announcement of discontinuance."
I used to be able to find internet documentation of this relatively easily, but today it was harder. I did still find http://www.directron.com/warranty-policy.html which says, "Lifetime is defined as the lifetime of the product on the market. Outdated technology is not covered by lifetime warranty if the item is no longer available on the common market as a new product."
cranes, welders, plasma tables, galvinization equipment, etc. that is required for us to build our product isn't just going to magically take less electricity just because we want it to.
The idea is that the controls will move from ad hoc human decisions (e.g. I'll flip on the welder now because I plan to use it in five minutes) to computer planned decisions (where work is scheduled for the welder so as to minimize the amount of time when the welder is warming up, etc.). The example given in the article is heating and cooling. For example, if you know that it will be hot during the day and cold at night, you can allow the temperature to gradually increase during the day and cool overnight if you only have a daylight shift.
Of course, we've been talking about doing this for twenty years. While this is the future, I don't know that it is particularly likely to take over in the next few years. It will gradually become more common, the way that it is now common for every automobile to have computer controlled fuel injection, valves, and sparking system rather than operate purely mechanically.
There are religion classes in public school
They are just elective, as they should be. But any kid wanting to learn comparative religion can do so.
There was no religion class in my public high school. I doubt that my high school was unique in that regard. I'm sure that your high school was not unique in offering them either, but saying that "any" kid can take comparative religion is just plain incorrect.
At some point the value of having exclusive functionality exceeds the merge costs, depending on a boatload of factors ranging from interface complexity and stability, business value, use by competitors, specificness of the issue solved and so on.
In the short term, that can certainly be true. However, what happens when you merge it for the fourth, tenth, etc. time? Especially as the merge tends to get more difficult over time. Also, note that the more work it is to add the functionality, then the more work it is to merge the functionality.
Another issue is that if the functionality is actually useful to someone else, someone will probably eventually upload it to the project in some form. If your company does this, then your upgrade path is usually pretty clear. If someone else does this, then the upgrade path can be far more difficult. Merging will also be more difficult (you may need to rip out functionality before adding your own).
Conversely, if your company is first to upload and your competitors need to migrate from their platform to your platform, that's often as much work as writing their own solution. In the long term, both of you will be better off, as you'll save on maintenance. In the short term, their migration is likely to cost enough that you don't lose by offering them your software.
There may be circumstances where it's better to hold your changes private, but those are going to be rare. Two competitors both using the same open source software as base but only one having implemented a particular feature. Said feature being relatively isolated from the rest of the codebase (such that there is little interaction that will be costly to merge). The feature being highly important to the business. Maybe. But event then, what happens if the competitor without the feature adds it? Then the first company has to either port their version or keep maintaining their version.
Also, the FDIC is slowly but surely ruining our financial economy. Why do you think lenders gave out so many subprime loans? Because the owners know that whatever happens, they are personally immune. Why do people no longer care to ensure that the S&L's they put their money in are financially sound? Because they know that they are immune,
This is why we should have full reserve banking (or at least increase reserves from 15% to 50%). Banks are over funded and loan out too much money. FDIC insurance should be limited to a $100,000 per person, not a $100,000 per bank account.
The truly ridiculous thing about the subprime mess is that it wasn't the mortgages themselves that caught the banks. Instead, it was the loans to the companies that bought the mortgages. In what way does it make sense to loan out money to buy something that is essentially a stock? The whole point of a stock is to allow people to risk the whole investment. Further, the whole point of securitizing the mortgage in the first place was to get the banks out of that risk. Why step back in by loaning money against the mortgage?
Someone has blown the whistle and turned on the flashing yellow klaxons to alert Virginia citizens and lawmakers to shoddy privacy practices. She's not trying to profit, she's probably not even trying to benefit from this work (except, perhaps in a very professional way).
Even better. There is a simple way for any municipality to get the information taken down from her site. All they have to do is stop displaying it publicly, let her know, and she removes the data. Ten of the municipalities listed have already done that. Of course, there are still eleven more that have not (including those with data for Jeb Bush in Florida and Colin Powell).
Her claim seems to be simple. If it's publicly posted on the internet, then it's not private and she can post it on her web site.
I'm not sure that I entirely agree with her thesis though. She seems to be saying that it's all right for this data to be public, just so long as it's not online. Personally, I don't think that any of this is data that needs to be public. The online part just makes it easier to access. In some ways, it would actually be easier to hide this data online (and limit access to the original physical records with the complete data). Then all the public data could be online and that part that is private (e.g. SSNs) would only be available to those few people that have real need to see the actual physical documents.
Sure, Google could aggregate the data and use it. Are they? They say they aren't yet. They may do so in the future. If they do, it won't replace the algorithm, it will just be added as an extra input.
Google sometimes tracks on what links users click in search results. They could use that data to reorder search results. If they do, is that using your brain to do work?
Google works by analyzing links around the web. These links are the results of people's decisions. Is that using your brain to do work?
Google says that they use the Google Image Labeler (GIL) data to improve image search results. There's no secret about it. The point is that there is no way currently to programmatically analyze a picture and come up with what it shows. Google created a system that collects human input.
By contrast, this system is wholly inappropriate for collecting that data. In GIL, they randomly assign images; in this, you choose the search. In GIL, they randomly assign you a partner; in the system you describe, they would be using the entire crowd. The problem here is that the system that you describe would be easy to game. With GIL, you would have to both be randomly assigned an image that matters to you and be randomly assigned a partner who also wants to corrupt the results. With the system that you propose, the people with the most incentive to use the system are those who want to game the results.
I think that you are underestimating the amount of analysis that would be needed to make use of this data. Ignoring the fraud problem for the moment, even if you only use the data from legitimate users, what would the data mean? If I label a search result "Jacques", does that mean that someone named Jacques appears in the result? That I think that someone named Jacques should appear in the result? That I think that someone named Jacques would be interested in the result? That I know a golden retriever named Jacques and this link is about golden retrievers? For the first of those possibilities (admittedly the most likely), this search result should appear when people search for Jacques. For the second, it should not appear and should be downgraded in the current search term (how could they forget Jacques!). For the third, perhaps it should be upgraded for the current search term. If you can find useful information in the fourth...
If MS Office drops in and does the job perfectly
Sure, but who has requirements that match MS Office exactly? With MS Office, if it does not match perfectly, you have to change your procedures to match the software. With OpenOffice, you could do that or you could change the software to match what you actually want to do.
It's also worth noting that there is nothing in the article or the press release about either office suite. The primary software to which they are referring is the operating system. With the operating system, the issue is generally that it is easier to configure a single MS Windows desktop than a single Linux desktop, so they go with MS Windows. However, if they spent the licensing money on support instead, they could get someone to configure the Linux desktops and still have left over budget to do customizations to better support their procedures.
They're also arguing that the people from whom they would buy the support would be local, while MS Windows is written in Redmond, India, etc. That argument doesn't hold much sway with me. If they are buying the software with Canadian dollars, then the only place to spend the Canadian dollars is in Canada. One way or the other the money will get spent in Canada, creating Canadian jobs. Perhaps not computer jobs because Canada may be more efficient at something else (e.g. providing weekend getaways in Vancouver for stressed out Microsoft employees from Redmond), but some kind of job.
Google has thus far always held that the only way to deal with this problem is automation, I find it really interesting to see them turn around like this and yield to the 'wisdom of the crowds'.
Crowds aren't involved at this point. All this does is allow an individual to change the ordering of search results on a page and add comments. Presumably the individual could come back to the same search later and see the same results, but there's nothing in the description of the experiment that suggests that anyone else would see this.
In the future, they might incorporate this as an additional input in their ranking algorithm, but at the moment, it's just for personal use.
The assumption in this case is that you already went through the low level area once. You are now returning to the area that you already beat purely because you need more experience points. It wasn't meaningless the first time; it's meaningless to repeat it once you've become sufficient powerful to make it easy to beat.
I think that you are looking at two different things:
Feanturi: being able to arbitrarily go to any place in the game and be competitive makes it hard to have a progressive and coherent story. This leads to boring games without good story lines.
Doctor_Jest: having the difficulty for a place in the game be such that you need to be level X to play it forces you into meaningless activities purely to gain levels. This is boring.
It's at least conceivable that one could address both concerns in the same game. Have scaling, but also have dependencies for various missions. If you haven't completed the dependencies for a mission, then the scaling should be set high (and NPCs should warn you away from that area and point you back where you should be).
It seems to me that Diablo II did that by simply prohibiting you from certain areas until you had completed the prior missions. However, the Diablo II scaling for necromancers was bad for me, as I got stuck needing a Blood Golem (IIRC) to defeat Andariel. This led me to grind for a while to get up to the necessary level.
Playing the game in story order (possibly with some side missions that are optional) while always being tough enough to be challenging but not so tough to be impossible makes for a more fun gaming experience. Making that happen with as few limits on gameplay as possible is difficult but should not be impossible.
The license under which you release your code is irrelevant with regards to patent law.
The difference is that the company holding the patent can't distribute the code under the GPL. Consider the case where you write code; someone else patents part of the basis for your code; now they redistribute the code that you wrote and charge their patent rent. With GPLed code, they couldn't redistribute your code (they'd have to write their own).
tangible results are measurable
Sure, but correlation is not causation. Let's assume that Iowa were not handing out tax breaks. What might happen instead? It's quite possible that the server farms would still go there (it's centrally located, cheap power, and low wages). Then they'd have all the current benefits plus higher tax revenues.
You can only measure results if you know what would happen without intervention. Without that, all that you are measuring is current state. You don't know if the current state is because of your change or despite it.
What is really needed is a secure version of DNS. It should be the site telling me that it is high security. This would cover both online banking (high security needed, in particular, verification of identity) and the personal router case (lower security).
Under the current system of DNS, my computer talks to my DNS server, which then goes to the root server, then it goes to the domain server. Since those connnections are plain UDP, they are easily subject to Man in the Middle attacks.
In a secure DNS system, my DNS server would have to supply credentials to establish identity and it would check credentials of its source servers. Then, when I request an online banking domain, part of the return information could be that only https is allowed and another part could provide a validation key. Then, when I get the certificate, I apply the validation key to verify the certificate. If the validation key fails, Firefox gives the current error and won't let you continue without jumping through serious hoops (or perhaps not at all).
Since we don't have a secure DNS, we can't do this, as it's currently too easy to provide false DNS results. With a secure DNS, we could do away with Verisign, et.al. in favor of DNS provider verification. Further, we would close all the other holes caused by having only insecure DNS.
The part that you're missing is that neither party is a cop in this. The point of entrapment is that the law officials can be really aggressive about getting the other person involved, after all, they aren't going to be prosecuted. Further, it's quite possible that the crime would not occur at all without the actions of law enforcement.
This isn't between your two situations; it's on an entirely different line. A better way of thinking about this is "What if it wasn't a scam?" If there really was a Nigerian trying to smuggle money out of the country, could you prosecute the other participant? If so, then the fact that it is a scam in this case is irrelevant. The victim would have acted in the same way if it had been real (to them it was).
The downside to prosecuting the victim is that it would lead to less victims coming forth. This would be clearly to the benefit of the Nigerian official (who has to do work when a scam is reported). However, it would make it less likely that the scammers on the Nigerian side would get caught. Thus, future victims would be more likely.
I would propose the following compromise. Victims who come forward on their own, don't get prosecuted. However, if the Nigerians discover additional victims when they arrest the scammers, those people should get prosecuted (especially if they don't realize that they have been victimized yet).
https://lists.ubuntu.com/archives/ubuntu-studio-users/2007-September/000472.html says that the difference between gksudo and sudo is that gksudo doesn't require invoking a terminal first. I.e. you can run the graphical application directly rather than inside a shell.
http://www.psychocats.net/ubuntu/graphicalsudo also points out that sudo often preserves the original users environment. As a result, running it with an application with a configuration file (very common for GUI apps) can cause the configuration file to end up owned by root (particularly if you run it under sudo before running it as a normal user).
Mozilla would have an easier time suing over 'Foxfire' if it is an internet browser than Microsoft had in suing someone for naming their product 'Lindows'. Neither fox nor fire has anything to do with internet browsing. As such, it is a defensible trademark in the internet browsing arena. It would not be defensible if the competing product actually involved setting flame to that breed of canid, as it would be generic then (in the same way that it was ruled that windows was a generic term in the US computing market).
Well, here's something: don't read it!
I think that the child reading it directly is less of an issue than having it come from someone else. E.g., I hear your dad doesn't love you (based on the mother's statement in the divorce case) or that your mom boinked the butcher.
It's also worth noting that children of divorcing parents are often depressed, and depressed people do things that are bad for them. It may not be the child who is concerned about being upset. It may be the parent who is concerned about the child being upset.
But even aside from the issue of functionality vs. security, there's the issue of security somehow being way more important in the browser, which I think is nonsense. Client-server apps have always had lousy security, and were easily hijacked. Just because they now run in a browser, the threat level hasn't changed. A hacker that is determined can break in sure, but they've always been able to break in. Nothing has truly changed, except for the perception of the threat level.
There are reasons why browsers are different from other client/server applications:
Part of the point of HTML5 is to make it easier to do things like implement a desktop application in the browser. As such, the comparison with the security of client/server applications is not appropriate. It's the equivalent desktop application's security that should be the goal.
It's also worth noting that the easiest time to add security is at the beginning. Once applications have been written to a certain model, it's expensive to change the model. Now, when there are no HTML5 applications, is the best time to make their security model robust.
The notion that people counting votes by hand is somehow always more accurate than a machine counted vote is ludicrous to me.
It's not more accurate; it's more verifiable. On average, even with some rather large machine errors, machines still probably have a lower error rate than hand counting. However, with the machine, you can count once and only once. If that's wrong the first time, it will still be wrong the second time. Machines act predictably on input. With paper ballots, you can go back to the original source of the data.
That said, it's perfectly possible to make a system that has all the advantages of the machine count but still have a verifiable, human-readable paper trail. You can't do that with these machines, because they weren't made that way.
How would such a machine work? The easiest way would be to simply print out the ballot; the voter reads it and verifies that they voted for Al Gore and not Pat Buchanan (the problem with the Florida ballots in 2000); the voter drops the printed ballot in the ballot box. If the ballot is incorrect, the voter puts the ballot back in the voting machine and redoes it. If it's still wrong, the voter escalates to an election official for further assistance.
It's worth noting that an optically scanned system can do the same thing. The important part is that the voter be able to see how the machine scores the ballot. A common problem in Florida was where two or more holes were punched. The voter should have redone the ballot in that case. If they had run it through a scoring system that told them that the ballot would not have counted their votes correctly, then presumably they would have done so. A side effect of that is that by adding up all the verification votes, you have an instant score. You only need to recount the ballots in an actual recount.
maybe what we need is a more verbose regex syntax.
What's really ironic about that statement is that Perl's RegEx syntax is actually one of the best parts of it. If you use /x, you can comment your RegEx and spread it over multiple lines. If you switch from the original // notation to {} notation, you can make it more readable (particularly when you need to use /s in your RegEx). Further, Perl supports embedding RegExes in other RegExes, e.g.
my $ALPHA = qr{[A-Za-z]}xsm;
my $NUMERIC = qr{[0-9]}xsm;
my $ALPHANUMERIC = qr{$ALPHA|$NUMERIC}xsm;
my $VALID_USER_ID = qr{$ALPHA $ALPHANUMERIC*}xsm;
if ( $user_field =~ m{$VALID_USER_ID}xsm ) {
# do something
} else {
# handle error case
}
(my syntax may be slightly off, I'm writing without a perl interpreter). In any case, the point I was making was that you can write self documenting Perl RegExes now. The problem is that you can also write horribly obfuscated RegExes.
The problem isn't that it is impossible to write elegant, maintainable code in Perl. It's that there are so many bad ways to write Perl code, chances are that at least one programmer who has worked on the script has done so. Especially since Perl maintains backward compatibility with all the stupid ways that things were done previously, which makes it hard for the interpreter to determine at compile time if something is stupid. It needs the run time context.
This isn't unique to Perl. I have the same problem with (the JAVA ORM) Hibernate's inability to tell me that I misspelled a column reference in my HQL until it fails catastrophically at run time (and its inability then to tell me which column reference is broken). This leads to a large number of Hibernate unit tests that basically implement compiler warnings by exercising code. However, it is very common in Perl.
IMO, it's not that Perl has passed its time. It's just that the language is not really intended for the purposes to which it is being put. It's not a highly maintainable language for user facing code. It's a system administrator language with its scripts intended to be run by the author of the script.
I'd pay for a new Battle for Wesnoth campaign. I'd love to see a bazaar arise, where multiple organizations provide images and story ideas, while all working on the same backend.
I doubt it'd work as well away from big lakes, or in areas where the ground leaks too much.
You don't need an existing lake. You can build one if necessary. Further, you can build both reservoirs out of materials that don't leak. I would think that the bigger problem is that you need the two reservoirs to be separated in height. I.e. you need hills. Meanwhile, many of the best places for wind generation are flat. Lakes are cheaper to build than mountains. Further, the reservoirs can be used as a water supply during droughts, etc.
Another alternative is to pump compressed air into caverns.
You may also need this kind of stuff for nuclear. The problem is that nuclear produces a relatively steady stream of power, while usage is bursty. Thus, use of natural gas and oil to provide on demand source to balance supply to demand. However, if we go with Pickens plan, we will stop using oil for this, and move the natural gas to use in powering automobiles. There are some biofuel alternatives (in particular, using landfill gas or other waste based generation works nicely with electrical generation), but it may be that this will not be enough.
Actually, radians is correct (it's the angular measure, two pi radians is equal to 360 degrees); the diameters is questionable in comparison.