December 11

Can anyone tell me why Google will not infrequently give you more results when you put in a limiter? I was just searching to buy long johns (cold winter a-coming) and I was getting results for a union suit, which I don't want, so I added to my search "-union" to reduce the hits—the results climbed from 4,000 to 14,000. What gives?--162.83.166.101 (talk) 01:25, 11 December 2009 (UTC)[reply]

Due to the rate and number of queries being processed, the estimate is a very shoddy estimate, really it is not an estimate at all. This doesn't come as much of a surprise. Chris Rocen (talk) 01:48, 11 December 2009 (UTC)[reply]

Thank you for the answer but that can't be the whole picture. When I have these results they are consistent. A month later the same search returns the same numbers. Everything you've said would lead me to believe that the results are almost random, and should fluctuate each time you hit the search button. No, there's something screwy about it but it's not that.--162.83.166.101 (talk) 03:30, 11 December 2009 (UTC)[reply]

No, I'm pretty sure it is. The google estimates are notoriously wrong, consistently. 219.102.221.182 (talk) 05:24, 11 December 2009 (UTC)[reply]

Sorry but none of this is helpful. There's no trenchant analysis here by someone who knows something. I don't mean that as an insult, but you're simply stating an apparent opinion with no analysis. You may be right that they are notorious wrong, but what you said earlier is inconsistent with actual data—the manner that they are wrong needs some explication other than "Due to the rate and number of queries being processed, the estimate is a very shoddy estimate."--162.83.166.101 (talk) 14:16, 11 December 2009 (UTC)[reply]

Answer from Google itself. Google uses the fastest algorithm it can to estimate the number of results returned. This is very likely not the most accurate one either. Caltsar (talk) 15:34, 11 December 2009 (UTC)[reply]

A similar confounding Google result prompted this question on Nov. 25. As I mentioned then, Google's search algorithms are proprietary and can change any time Google desires - whether for technical, business, or other reason. This was one of the motivating principles behind Wikia Search - the goal was to make the search algorithm transparent so third-parties can evaluate the utility, validity, and efficiency of a particular algorithm. Unfortunately, Google has no desire to expose its internal workings, so we're left to speculate wildly about what might cause such spurious results. Nimur (talk) 16:58, 12 December 2009 (UTC)[reply]

Language Log has done some interesting investigations into google's algorithms for determining estimates (and specifically their inability to cope with estimates for boolean queries), see [1] and [2] for instance. Belisarius (talk) 02:51, 14 December 2009 (UTC)[reply]

What's that date system called (if it has a name)? Where dates are represented as a count starting at the date in the title and 11 dec 2009 is 15321. -202.124.72.52 (talk) 03:07, 11 December 2009 (UTC)[reply]

See Epoch (reference date)#Notable epoch dates in computing. If 1 January 1960 is day 1 then 11 December 2009 is actually day 18243. There are 15321 days from 31 December 1967 to 11 December 2009 so it appears your count is the same as used in Pick operating system. PrimeHunter (talk) 03:41, 11 December 2009 (UTC)[reply]

OP here. 1968 is what I meant. Oops. And it is indeed in a Pick related system - a UniVerse database. Thanks -202.124.74.1 (talk) 04:12, 11 December 2009 (UTC)[reply]

A Julian Date does the same thing, but with a different start date. Ariel. (talk) 09:37, 11 December 2009 (UTC)[reply]

My Dell has a "dell wireless 1397 g half mini card" wifi card. Can this card utilize and access networks that broadcast in just a or b signals? Acceptable (talk) 04:38, 11 December 2009 (UTC)[reply]

B and G are cross-compatible, so it should work just fine on a B network. Unless it specifically indicates support for A though, it won't have it. —ShadowRanger ^(talk|stalk) 04:42, 11 December 2009 (UTC)[reply]

A is a more "advanced" signal, with better speeds. It's not particularly common in public venues. Shadowjams (talk) 08:59, 11 December 2009 (UTC)[reply]

And uses a much higher frequency (~5 GHz vs ~2.5 GHz) so requires completely different radio kit. --Phil Holmes (talk) 10:02, 11 December 2009 (UTC)[reply]

If several people accessed the same php scrip on a server at exactly the same second, say for example a simple script which logged ip addressed, what would happen? Would the script qew the requests or would it just fail —Preceding unsigned comment added by 82.43.88.54 (talk) 15:23, 11 December 2009 (UTC)[reply]

It depends on how the server is set up, how many simultaneous connections it tries to juggle, whether it is multithreaded, etc. In any case a script will not automatically queue requests—when writing scripts that deal with writing to files or databases you have to take into account the possibility that the resource will already be locked by another process. That means you can't have your IP logging script just die out if it can't open the log file. BBClone does a nice job of this: it has a number of possible queue files that it can write to, and it tries to find just any one that is writable, and then writes to it, and then later instances of the process look for queued material yet to be written to the master file. At the bare minimum you want to make sure you are locking the files you are writing to when you are doing so because otherwise you run the risk of corrupt data and etc. For a basic overview see flock. Scripts that write every time a page is accessed (like an IP logger) are actually among the most important to get this kind of thing right for (they are not "simple" from that point of view at all, compared to scripts that write only occasionally). --Mr.98 (talk) 15:34, 11 December 2009 (UTC)[reply]

A while loop in PHP is very handy to tell the script to attempt the lock until it's successful, if the script is only dealing with one file the chances of a deadlock are minimal. --66.195.232.121 (talk) 16:28, 11 December 2009 (UTC)[reply]

Though such a thing can lock the whole site if for some reason the lock never successfully opens. For a small project, an endless-attempt loop is fine, but for something serious, you'd want to have some way for it to fail without breaking the whole script. (And there are accounts on the flock page linked above of just such things happening with some OSes that don't release file locks correctly 100% of the time.) --Mr.98 (talk) 20:18, 11 December 2009 (UTC)[reply]

A simple, practical answer to your question is no, there would be no failure or even a queue unless the number of requests was in the hundreds per second for a sustained period. When a connection is made to a web server, regardless of script activity, there is a unique process assigned to handle that request. These processes can number in the hundreds or thousands depending on the server hardware and software configuration. When a script runs to handle the request, a copy of it runs under the guise of that process. Just because there is only one script file on the server, does not mean that one instance of the script has to handle all the requests. If there is some additional, finite resource (like a file that every copy of the script uses) then the access to this file does need to be balanced in such a way to avoid conflicts. If the action by the script is simply to append an IP address to the file, then the chance of a conflict is exceedingly small even given a LOT of requests. Normally when you edit something the file is being locked, read, written back, and then unlocked. When you append an IP address (especially in an efficient OS like Unix or Linux) the file handle is being locked only long enough to put a handful of bytes onto the end of it, then it's unlocked. This can happen in milliseconds even on average hardware, so it would require hundreds if not thousands of requests a second in order for this to be a bottleneck. To give a little more detail, the process that PHP uses to track individual sessions (in its default configuration) is far far far more resource intensive, so it is more likely to be a bottleneck than any sort of simple disk operations like building an IP list of visitors. Lastly, the process of writing the IP and a heap of other unique information each time a web request comes in is something that happens by default on web servers anyhow, and it is rarely a resource issue; more often it's a matter of these files taking up too much space on the disk and not that they take up too much time to write out. --66.195.232.121 (talk) 16:15, 11 December 2009 (UTC)[reply]

The first limitation that comes to mind is whether the web server supports simultaneous requests. For example, Apache is set up to handle 256 simultaneous requests by default, but it can be changed by the administrator. PHP will limit the wall-clock execution time of its threads, so if too many simultaneous requests result in failure to process quickly enough, the processes will die. See PHP Connection Handling for details. Similar restrictions may be imposed by the operating system, the network / NAT / firewall, etc. So, it depends on your system setup. Nimur (talk) 17:32, 11 December 2009 (UTC)[reply]

A web server not set up/not capable of simultaneous requests is, I believe, called a "book". --66.195.232.121 (talk) 18:50, 11 December 2009 (UTC)[reply]

Other problems, if not properly handled, can include data hazards and race conditions, if the script accesses any shared resource (like a log file). For these reasons, you may want to consider a thread safe solution, like certain relational databases; or implement your own parallel thread protection measures in PHP using locks or synchronization. For example, look at PHP's flock() to lock files. Nimur (talk) 16:26, 13 December 2009 (UTC)[reply]

Do we have a page on the "secret question" password authentication scheme that one often finds on all sorts of websites? (You know, "What was your first pet's name?") It seems like a bafflingly bad idea to me (half of these questions are known by my old friends and family members, who are not necessarily among those I would want to have access to my online banking, etc.!) and I'm kind of interested in how they've become so ubiquitous, but I'm not really sure what the proper terminology is. --Mr.98 (talk) 15:24, 11 December 2009 (UTC)[reply]

AFAIK Wikipedia does not use any such pseudoauthentication, the only accepted methods are password reset and (of course) logging in with your password, but I have seem some people verifying strong SHA hashes before and getting their password reset by a dev. Chris Rocen (talk) 15:37, 11 December 2009 (UTC)[reply]

(EC) I can't find any articles that discuss such authentication in any detail. One common method to eliminate the problem you mention is to answer the questions "incorrectly". For example, if the question is "what was your first pet's name?" you might put in "Volkswagen", and if the question is "what street did you live on when you were 10 years old", you'd put in "Kitty cat", etc. Obviously you have to remember what you've put in for any given question, but your friends and family members would be likely to just answer the questions as presented. --LarryMac | Talk 15:42, 11 December 2009 (UTC)[reply]

Oh, right, sorry. I misread the question. Chris Rocen (talk) 15:43, 11 December 2009 (UTC)[reply]

Sarah Palin email hack tells us that Rubico wrote that he used the Sarah Palin Wikipedia article to find out Palin's birthday in "15 seconds", one of the standard security questions used by Yahoo (my emphasis). (Which suggests to me that "security" means squat, or at least that it means squat when configured by a pit bull.) Sorry, this is the best I can do offhand. Incidentally, I always give fictional answers to these questions myself. -- Hoary (talk) 15:44, 11 December 2009 (UTC)[reply]

Well, especially for public figures. I mean, even the "harder" ones (I just had to make up one of these for a service I am billed for regularly) are pretty easy to find out for public figures. ("What is your oldest nephew's name?" "Where did you go to elementary school?" — These are not exactly "secret".) Anyway, yes, I know you can subvert them—I'm just curious about the general trend. I suspect most people are not very security conscious about this (or anything else) and use real answers, which makes it quite a ridiculous security breach, really. --Mr.98 (talk) 16:11, 11 December 2009 (UTC)[reply]

Incidentally, we do have an article - Knowledge-based authentication - but it is rather stubby. --LarryMac | Talk 16:12, 11 December 2009 (UTC)[reply]

Nice find. I just made Secret question a redirect to Knowledge-based authentication. Comet Tuttle (talk) 17:44, 11 December 2009 (UTC)[reply]

Secret question isn't a good name for it. It is secret answer. Everyone can see the question. Only the user has knowledge of the answer. Well, only the user is supposed to have knowledge of the answer. -- kainaw™ 17:49, 11 December 2009 (UTC)[reply]

From a language standpoint, I agree, but a Google search for "secret question" returns millions of results, many of them discussing the fallibility of the system. --LarryMac | Talk 17:52, 11 December 2009 (UTC)[reply]

Good point, Kainaw, I just made "secret answer" a redirect to it, too, and LarryMac is of course right when he implies that redirects are often for the convenience of confused users. Comet Tuttle (talk) 18:33, 11 December 2009 (UTC)[reply]

We also have security question, which is the name I see given them by most websites using them. Do we need a merge? --Tardis (talk) 15:24, 15 December 2009 (UTC)[reply]

Can someone put a capital "S" in suoerscript on ther that is unicode, or something else that can be copy-and-pasted into a Facebook name, with Facebook unsuperscripting it. Thanks. :) Chocolate muffins in a basket 18:09, 11 December 2009 (UTC)[reply]

In superscript it has quite a few letters:ᴬ ᴭ ᴮ ᴯ ᴰ ᴱ ᴲ ᴳ ᴴ ᴵ ᴶ ᴷ ᴸ ᴹ ᴺ ᴻ ᴼ ᴽ ᴾ ᴿ ᵀ ᵁ ᵂ, but S is not there. However there is lower case s which is smaller: ˢ. ˢ Graeme Bartlett (talk) 21:57, 12 December 2009 (UTC)[reply]

Thanks. That's perfect. Chocolate muffins in a basket 13:04, 14 December 2009 (UTC)[reply]

This is my first digitial camera and 5 years old now. Recently when looking through the LCD or reviewing pics on it, the images are distorted in terms of color - the closest analogy I can relate this to is if you take a photo of a TV on, but minus the lines and frames refreshing. The main issue is with the color distortion and slightly wavy lines around objects. However the pics look fine when offloaded, it's just when taking them and reviewing them that things look off. This started to come up sporadically, but now appears to be a permanent condition. There is a manual viewfinder so I can sort of still work around this, however I tend to use the LCD. Any ideas or workarounds (besides buying a new camera) ? Thanks. BrokenSphere^{Msg me} 18:32, 11 December 2009 (UTC)[reply]

Your LCD on the camera is indeed flaky and/or dying. When this happened to me, I just used the manual viewfinder, and went out of my way to manually push the button to turn off the LCD each time I turned on the camera; and I consoled myself with the knowledge of how much battery life I was saving without the LCD. Until I bought a new camera. Comet Tuttle (talk) 20:09, 11 December 2009 (UTC)[reply]

Given that the camera is five years old it clearly won't be economical to attempt a repair of the LCD, so I think you'll just have to live with it if you don't want or can't afford, to buy another camera. Rjwilmsi 20:20, 11 December 2009 (UTC)[reply]

I disagree that it won't be worth repairing. I had a 5 year old Sony DSC-L1 made good as new for a quite reasonable price, although I won't mention the name of the repair place here so as not to spam. If BrokenSphere likes his camera, it is at least worth examining all the options. --LarryMac | Talk 21:00, 11 December 2009 (UTC)[reply]

It may be that the LCD itself is fine, but that its connection to the camera's PCB is defective. In particular the connector where the LCD signal is connected to the PCB may have worked loose. If you're sufficiently careful, you should be able to open the camera's case without disturbing the optics, allowing you to attempt to reseat the connection. Typically (although not universally) the LCD is integrated with a brown or green flexcircuit, a ribbon of which bends down to the main PCB. There it means a crimp or elastomeric (zebra-strip) connector. Try pushing the ribbon more firmly into the connector (it may have become partially dislodged due to mechanical or thermal stress). If that fails, unclipping the connector, massaging the elastomer with something like a small screwdriver, and then reconnecting the cable may help. Obviously make sure the camera is unpowered and that you take proper ESD precautions. Of course, as with all such operations, you run the risk of taking a working-but-deficient camera and rendering it entirely broken. -- Finlay McWalter • Talk 20:47, 11 December 2009 (UTC)[reply]

Long term, does this pose any issue for how the pics will turn out other than the inconvenience of seeing distorted colors? BrokenSphere^{Msg me} 22:13, 11 December 2009 (UTC)[reply]

According to this link, you can get another A340, refurbished, for $76.00. Prices on new models have come down since 2004, so just replacing with a state-of-the-art camera may be best. EdJohnston (talk) 21:12, 11 December 2009 (UTC)[reply]

Thanks for the input. I'm planning to get a new point and shoot eventually when I can. Another issue with this camera is that the switch no longer works to go back to wide angle after zooming in, so for me it was already half useful, but it still works, just seems to be falling apart now. I was curius as to what could be a solution to the LCD issue given that it just came up recently. BrokenSphere^{Msg me} 21:26, 11 December 2009 (UTC)[reply]