Wikipedia:Reference desk/Archives/Computing/2010 November 27

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Computing desk
< November 26 << Oct | November | Dec >> November 28 >
Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

November 27[edit]

.tar.gz is a compressed file in a compressed file?[edit]

If so, why? ----Seans Potato Business 00:06, 27 November 2010 (UTC)

The .tar on its own usually does not use compression. .tar#Compression_and_naming explains in detail (talk) 00:21, 27 November 2010 (UTC)
(ec) tar doesn't compress files, it just archives them, i.e. concatenates them together along with some metadata like file names, modification times, and so on. -- BenRG (talk) 00:22, 27 November 2010 (UTC)
".gz" files are GZIP files - see Exxolon (talk) 04:17, 27 November 2010 (UTC)
Indeed, tar on its own can produce a significantly larger file than the original, because it was designed for writing to tape (that's what the t stands for) and writes in multiples of 512 bytes at a time. However, since disks these days are written in larger blocks than that, the actual disk space consumed by an non-compressed tar file is likely to be no more than that of the constituent files. --Anonymous, 06:10 UTC, November 27, 2010.
The other important thing is that a .gz is a single compressed file, unlike a .zip file, which compresses many files. Paul (Stansifer) 21:19, 27 November 2010 (UTC)
Unix philosophy ¦ Reisio (talk) 16:26, 27 November 2010 (UTC)
Ceci n'est pas... Marnanel (talk) 16:36, 27 November 2010 (UTC)
O tempora… ¦ Reisio (talk) 02:18, 28 November 2010 (UTC)
Briefly, in unix philsophy the goal is to break functions down so that each logical step has it's own program. This way unix commands can be combined in ways the original programmers never thought of.
In this case zipping a file has two steps, putting all the files into one big file, then compressing the big file. The "tar" file is the one big file, and when it's compressed the ".gz" is added. (Sometimes the two extensions are shortened to .tgz so as not to freak out certain older filesystems.) APL (talk) 21:53, 28 November 2010 (UTC)

darknet search engine[edit]

i remember reading this article on search the deepnet and this article dwelt on how advertisers and companies were using it to spy on people and discover habits. one thing i remeber of one these sites is that they offered to delete the info in the stuff uve done if u give them ur email id . does any one know any thing about the site.Metallicmania (talk) 16:25, 27 November 2010 (UTC)

Have a look at Ixquick and Criticism_of_Google#Privacy.Smallman12q (talk) 22:08, 27 November 2010 (UTC)

Copy and paste problem with emails that are not plain text--solved![edit]

Referring back to this question, I have been having a problem with text that included symbols and other items that I copied and pasted into emails that were not plain text, ever since the introduction of Internet Explorer 8. Today, the text copied just fine.

I know of one thing I did in recent weeks. Java has been nagging me for months to do an update. I was always scared to add new software because it might cause problems, but I decided to go ahead this week.

One other thing is different. For some reason spaces between paragraphs didn't copy in the past. They did today.

Something else is happening and I'd like to know how to reverse it. On one of those sites with the symbols and other stuff, I no longer see "[FONT="San Serif"]text[/FONT] or [COLOR="Blue]Text[/COLOR]. I can only see what was done, not how. But if I don't know the name of the color, or the font or its size, I don't know how to do this. I want to be able to see these items again.Vchimpanzee · talk · contributions · 17:19, 27 November 2010 (UTC)


æ is included with the accented characters in Unicode, so why isn't œ? Between accented "o" characters and accented "u" characters, there's even a space used for the division sign. Why did they put that there instead of œ? -- (talk) 19:01, 27 November 2010 (UTC)

To clarify your question: are you asking why the specific code-points for æ and œ are not near each other in the Basic Multilingual Plane? I think the concise answer is "because" - and the elaborate answer is that there are literally tens of thousands of code-points for various glyphs; the BMP attempts to place the "most common" glyphs in one single plane (a grouping of 65536 code-points); and attempts to sub-organize these as contiguous blocks of "related" code-points. Æ falls into the C1 Controls and Latin-1 Supplement block and Œ falls into the Latin Extended-A. So, at some point in history (probably before Unicode was even formulated), some engineer or linguist decided that Æ was a "supplementary" Latin character and Œ was an "extended" Latin character. Why? For the same reason that dž is assigned to code-point U+01C6 instead of being placed near the regular letter "d." There's no possible way to make a linear "alphabetical listing" of all possible code-points, while preserving all possible similarities between all possible glyphs. Unicode is not intended to place "similar-looking" glyphs near each-other. It's intended to provide a consistent encoding, representation and handling of character-points that represent the most common forms of human writing. It inherits some legacy code-point organization from ASCII and earlier ISO standards, too; and those were not as well-thought-out as Unicode. For further reading, see ISO/IEC 8859-1 - which is the specific legacy-encoding that is superseded by BMP U+0000 to U+00FF. Specifically: "Languages commonly supported with nearly complete coverage of their alphabet - French – missing the ligatures Œ and œ as well as the very rare Ÿ (they are generally replaced by digraphs OE and oe, and Y without the diaeresis) (Windows-1252 and ISO-8859-15 do contain these))." In other words, in a previous era, somebody decided that Œ was unneeded. Nimur (talk) 20:18, 27 November 2010 (UTC)
The short version is that the first 256 code points of Unicode were copied from ISO/IEC 8859-1 (Latin-1), which contains æ but not œ. I'm less sure why it was omitted from Latin-1. There are some odd inclusions/omissions in Latin-1 and, for that matter, in ASCII. The placement of × and ÷ in Latin-1 is interesting and makes me wonder if they were a last-minute substitution. -- BenRG (talk) 21:11, 27 November 2010 (UTC)
8859-1 was intended to support western European languages and it was decided that œ wasn't needed for any of them. What I've read (but I don't know where, to cite it) as that at that time the French considered that "coeur" and "cœur" were just typographical variants of each other, like "fit" and "fit" in English, so there was no need to take up a valuable code point for œ. Later they changed their minds and the result is ISO 8859-15, which was meant to replace 8859-1, dropping such handy characters as ÷ and ½ in order to add œ and a few others. Then Unicode, of course, included everything. --Anonymous, 04:00 UTC, November 29, 2010.

Polling (Mouse)[edit]

I have purchased a gaming mouse which has an option named "polling". The configuration of this feature is: 100 T/S, 500 T/S and 1000 T/S. However, I have set it to default state, 500 T/S. I have no idea about "polling" feature. What is it for and what function does it do? What if I increase the number to 1000 T/S? thanks-- (talk) 21:40, 27 November 2010 (UTC)

It it is the Times / Second the mouse updates its position. So higher should be better with regards to lag, but I guess there's some kind of a trade-off since it's customizable. -- (talk) 22:03, 27 November 2010 (UTC)
See Polling (computer science). It would probably increase the accuracy of the mouse...though the default windows setting is 125 T/S. Increasing past 500 won't do much unless you're in gaming/art or other related programs where a pixel might make a difference. Past 500 would be wasting cpu cycles.Smallman12q (talk) 22:04, 27 November 2010 (UTC)