Computing desk
< October 3	<< Sep \| October \| Nov >>	October 5 >

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.

October 4

system font del Capitán

I just noticed that in OS X El Capitan the system font is no longer Helvetica. Anyone know what it is? —Tamfang (talk) 06:29, 4 October 2015 (UTC)[reply]

Wikipedia:WHAAOE: San Francisco (2014 typeface) 731Butai (talk) 08:18, 4 October 2015 (UTC)[reply]

Sometimes the tricky part is knowing where to look. — I wonder why it doesn't show up (at least by that name) in Font Book. —Tamfang (talk) 04:54, 5 October 2015 (UTC)[reply]

...You aren't going to believe this, but it doesn't show up because it's not installed. (See my earlier response, below, for detailed information about how this confusing statement works in practice). If you wish to install this font for use in anything-other-than-the-built-in-system-UI, you need to download it: the main Fonts page for developers links to San Francisco for iOS; and for more information regarding font types on iOS and OS X; and you need to sign a developer licensing agreement.

Introducing the New System Fonts, from WWDC 2015. Nimur (talk) 01:04, 5 October 2015 (UTC)[reply]

Grover's Algorithm

In the atricle about Grover's algorithm in the second (and last) figure : why after performing $U_{\omega }$ on $|s\rangle$ , the result is not at the left of $|\omega \rangle$ as for a reflection around $|\omega \rangle$ ? 80.246.136.92 (talk) 09:40, 4 October 2015 (UTC)[reply]

For whatever reason, the definitions of U_ω and U_s differ by a sign. U_ω is a reflection through the plane normal to ω, while U_s is a reflection through all axes perpendicular to s (or the negative of a reflection through the normal plane). See the first two formulas in Grover's algorithm#The first iteration. -- BenRG (talk) 00:05, 5 October 2015 (UTC)[reply]

I'd thought that the reflection is around

|\omega \rangle

. Thank you! 185.32.179.149 (talk) 17:43, 5 October 2015 (UTC)[reply]

Trace route

when u do a trace route u see many different companies in the hops. can they see your internet traffic? 62.37.237.15 (talk) 10:53, 4 October 2015 (UTC)[reply]

Yes, that's how the internet works. Usually the traffic goes from your ISP to their upstream provider, often to a national provider, through a Internet exchange point, over an international connection, through another IXP, and back through another chain of suppliers. Yes, they can all see your traffic, and so can governments which force them to provide the government with a copy of the traffic. That's why encryption on the internet is so important. 2.126.122.210 (talk) 12:41, 4 October 2015 (UTC)[reply]

The usual analogy given is that unencrypted traffic is like a postcard. Anyone handling it can look at what you're sending without your knowledge. --71.119.131.184 (talk) 07:38, 5 October 2015 (UTC)[reply]

Finding Unitary transformation

I am looking for some Unitary transformation that satisfies $T(\alpha |0xz\rangle +\beta |1yz\rangle )=|1yz'\rangle$ where $|x\rangle ,|y\rangle \in \{|0\rangle ,|1\rangle \},|z\rangle =|000...\rangle ,\alpha ^{2}+\beta ^{2}=1$ ( $|z\rangle$ is actually grabage for storing another data, if needed), and I can't find one... 31.154.92.179 (talk) 13:16, 4 October 2015 (UTC)[reply]

I think this is impossible, though it's not obvious to me how to prove it. T is linear, so, for example,

|000\cdots \rangle

needs to map to a constant output independent of which vector starting with

|1\rangle

you've added it to, but you seem to need it to map to different things depending on that other vector. -- BenRG (talk) 17:00, 5 October 2015 (UTC)[reply]

Why it's a constant?

T(|000...\rangle +|x\rangle )=T(|000...\rangle )+T(|x\rangle )\neq T(|000...\rangle )+T(|y\rangle )=T(|000...\rangle +|y\rangle )

, so the result depends on the other vector (whether it's

|x\rangle

or

|y\rangle

) too 185.32.179.149 (talk) 17:41, 5 October 2015 (UTC)[reply]

Assume also that

\alpha ,\beta

are fixed, and

\alpha \approx 1,\beta \approx 0

. Then, what Unitary transformation does this? 80.246.136.9 (talk) 05:47, 6 October 2015 (UTC)[reply]

Here's a proof: unitary transformations preserve inner products, so we have

({\bar {\alpha }}\langle 0xz|+{\bar {\beta }}\langle 10z|)(\alpha |0xz\rangle +\beta |11z\rangle )=\langle 10z'|11z''\rangle

which reduces to |α|² = 0. So there is no solution when α ≠ 0. (There are solutions when α = 0, such as the identity function if β = 1.) -- BenRG (talk) 07:22, 6 October 2015 (UTC)[reply]

It's a beatuiful proof! Thank you! 31.154.92.179 (talk) 15:44, 6 October 2015 (UTC)[reply]

Searching for terms and specifics on FB groups

Some of the FB groups I'm a member of have huge amount of posts daily. However, a lot of it is reposts and rubbish that I'm not interested in.

Is there any way to search for what I want based on terms, as occasionally buried beneath the clutter there are some gems.

From what I can tell, the way the group works is as you scroll down it loads additional portions of content. So just using the search facility in my browser seems to be inadequate without having to spend a lot of time scrolling down, waiting for sections to load which again isn't very efficient. — Preceding unsigned comment added by 80.195.27.47 (talk) 16:38, 4 October 2015 (UTC)[reply]

Most of the groups I belong to, somewhere near the top of the group's main page there is a magnifying glass search bar that lets you search for members of the group or content in the posts to the group. RegistryKey^(RegEdit) 07:48, 5 October 2015 (UTC)[reply]

Semi-transparent window in legacy RHEL/CentOS?

Is there any evidence that the X server in CentOS 4 (or Red Hat Enterprise Linux 4) really supports compositing? After I added the following settings to /etc/X11/xorg.conf:

Section "Extensions"
        Option          "Composite"     "Enable"
EndSection

I noticed that the composite extension appears in the output of xdpyinfo:

[root@localhost tmp]# xdpyinfo
    .            .
    .            .
    .            .
number of extensions:    31
    BIG-REQUESTS
    Composite
    DAMAGE
    DOUBLE-BUFFER
    DPMS
    .            .
    .            .
    .            .

We want to adjust the window opacity on-the-fly in our Qt application. It seems that enabling compositing is the way to go (otherwise we may need to emulate the transparency effect by contents propagation). But weird artifacts appears after composite extension is turned on. Is it because xdpyinfo reports incorrectly or something?

Version info. in the system:

CentOS: 4.8

Xorg: 6.8.2

metacity window manager: 2.8.6

Migrating to newer CentOS version should resolve the problem, but our application is too complicated to do the migration easily in short time. - Justin545 (talk) 17:17, 4 October 2015 (UTC)[reply]

nul device that remembers

Is there a feature like the ">nul" device that writes data to a non-existent place, except instead of discarding the data immediately it keeps say 10 items in RAM and removes the 10th item every time a new item is written to it. The 10 items can be accessed like normal files. The number 10 is an arbitrary number, it could be 1 or 1000000 doesn't matter. Thanks for your help. — Preceding unsigned comment added by 109.251.203.41 (talk) 20:45, 4 October 2015 (UTC)[reply]

Somewhat similar in concept, in Unix there is a /tmp directory where temporary data was written, and a daemon was run each night to erase it all (where I used to work). StuRat (talk) 21:07, 4 October 2015 (UTC)[reply]

Your question is not well defined. When you say "is there a feature like", do you mean anywhere in the entire history of computing? Do you mean in a specific operating system or program or programming language? Many programs have a command history or an undo history, many operating systems have a clipboard or scratch disk, they're all "sort of" a place that hold data written to them. Vespine (talk) 02:51, 5 October 2015 (UTC)[reply]

Named pipe is also somewhat similar to what you want, but it doesn't have a limit to the number of items written. The program tail can show you the last 10 (or whatever number you specify) lines in a file. We may be able to give you better help if you tell us more about what you want to use such a device for.-gadfium 03:05, 5 October 2015 (UTC)[reply]

That would not be a 'nul' device, because a null device by definition does nothing to data transmitted to it. It does not copy, does not store, does not transmit it anywhere – it just ignores anything you put there.

IMHO a device you described may get called a 'limited queue' or better a 'tail queue' or a 'cyclic buffer' device. I don't know of such device built-in into any operating system, but see gadfium's reply above for a Unix/Linux-like command-line tool example. --CiaPan (talk) 14:35, 5 October 2015 (UTC)[reply]

I can see that there might be a use for a modified version of nul that logs instead of ignores. It could help in troubleshooting certain situations. The question is, does such a modified nul device exist for Linux or BSD?? Is there some sort of logging utility that does the same basic function in Windows?

The question of preventing a log from growing too large by discarding the oldest entries seems like a separate problem, and one that already has multiple solutions. --Guy Macon (talk) 15:25, 5 October 2015 (UTC)[reply]

On Unix, to save output, you just redirect it to a file. my_command > my_file is routine. To throw away the output, you just point it at /dev/null instead. If you want to do fancier things, you can use a pipe or socket that's read by another process. So, there isn't any real need for a "modified nul device" on Unix, since things are really the other way around: /dev/null is just a special file. One of the big ideas in Unix is "everything is a file". Regarding the original question, I suspect we might have an X-Y problem here, so I'm going to refrain from trying to give a broad answer. Can the original poster give specific details of what they're trying to do? --71.119.131.184 (talk) 18:57, 5 October 2015 (UTC)[reply]

Would that capture everything sent to nul by any part of Linux or BSD? I already know how to make any program I choose send output wherever I choose, but is it possible (for troubleshooting purposes only) to see everything going to nul no matter what obscure library or device driver sends it? The key here is seeing things that you didn't know were being sent to nul. --Guy Macon (talk) 04:25, 6 October 2015 (UTC)[reply]

I think there is a way to capture the null-device data. Just remove the special file /dev/null entry from the filesystem and replace it with a normal file. Then it will capture all the output from all processes in the system, that normally goes to a sink. ;) You might also try to rebuild the system with your own null–device driver.
However, if you want to capture just the null'ed output of a single process, I have no idea how you can achieve that. I imagine you would have to replace a system driver for a null device and build-in some command to switch its operation mode (say to switch logging on and off, or to define process ID of the process, whose output should get logged)... --CiaPan (talk) 12:08, 6 October 2015 (UTC)[reply]

Ideally you just stop the process from ever opening /dev/null in the first place. You're going about things backwards. If something (like a shell script) is starting the process and pointing it at /dev/null, change that. If some configuration file is telling it to write to /dev/null, change that. If the program is hard-coded to write to /dev/null, and you have the source, change that and rebuild it (and maybe complain to the author(s)). If none of those are feasible, you can start the process in a chroot jail, container, or whatever and ensure /dev/null is a regular file inside it, or start it under the control of a debugger and intercept calls to open(/dev/null, .... --71.119.131.184 (talk) 12:34, 6 October 2015 (UTC)[reply]

It occurred to me if you're not familiar with Unix, you might not understand what I'm getting at above. /dev/null is never open by default on Unix. The only default file descriptors (fd for short) on Unix are stdin, stdout, and stderr. So if a process is writing to /dev/null, it either inherited from its parent a file descriptor pointing at /dev/null, or opened /dev/null itself. To illustrate, when you run foo > /dev/null in a shell, the shell fork()s a child, and the child redirects stdout to /dev/null before exec()ing "foo". This is a really good primer on how processes on Unix work. We've also got a number of articles on that discuss Unix: fork-exec might be a good starting point. --71.119.131.184 (talk) 14:14, 6 October 2015 (UTC)[reply]

Certainly anyone who is moderately able to write C code could write such a thing for UNIX/Linux using a named pipe. The pipe would feed a daemon of some kind that would read from the pipe, and maintain the "most recent N items" someplace on disk. Most of the time, the daemon would be blocked waiting on it's read request, so it would only consume resources when there data is actually being written to the pipe. If you place the pipe in /dev/notQuiteNull (or whatever) then it would then "just work". It's probably something that could be written in a few dozen lines of code. Start the daemon when the operating system boots up. There might be issues if multiple processes tried to write to your named pipe at the same time, but I'm sure those can be resolved. SteveBaker (talk) 18:43, 5 October 2015 (UTC)[reply]