Some questions I've pondered, and my answers, which may or may not be correct. This stuff didn't seem to fit anywhere else at the time.
- Q: Why are PF_UNIX sockets the only means of exchanging file descriptors (why not regular pipes? why not PF_INET or PF_INET6 sockets?)
- A: The socket infrastructure provided sufficient mechanism -- recvmsg(2)/sendmsg(2), struct msghdr etc. Regular pipes don't have out-of-band signaling capabilities, as used by the SCM_RIGHTS cmsg_type. File descriptors index a kernelspace array, and thus any non-local socket family would introduce the possibility of a copy of those structures (if that is even meaningful and possible in a given context). Furthermore, they're credentials, in that access checks have already been performed; a socket family involving peers not trusted by the local kernel could subvert the access control.
- Q: How do I get a list of fonts known to fontconfig?
- A: fc-list
- Q: How do I get the start address of an ELF binary?
- A: readelf -h binary | grep "Entry point address:"
- Q: How can I run program as sudo over X? It says it "can't connect to X server at localhost"!
- A: sudo -E program (you need to preserve your DISPLAY variable. -E preserves environments)
- Q: How can I merge one directory into another?
- A: find srcdir -depth -print0 | cpio -pdm0 targdir. This uses cpio's passthrough mode.
- Q: Why doesn't du take an -i argument for inode usage?
- A: It's difficult (and impossible for regular users) to map directory hierarchies to inodes.
- Q: How can I discover a module's parameters?
- A: modinfo -p modname
- Q: How do I remove an obsolete broken package from Debian upon getting the error "This might mean you need to manually fix this package"?
- A: dpkg --force-remove-reinstreq --remove pkgname
- Q: How can I search for string in package descriptions on Debian?
- A: aptitude search '~dstring' (among other ways)
- Q: How do I get a list of all a display's clients?
- A: xlsclients
- Q: How do I get a list of every window?
- A: xwininfo -root -children
- Q: Why aren't "target"-style #includes a good idea with any sane compiler?
- A: So long as you can append to the default include search path (ie, the -I option to gcc), the <target>-style include can search in your project directory. Building from the source toplevel, a simple -I. added to CFLAGS allows #include <toplevel/relative/filename>. Moved headers will trigger a preprocessing failure. If "target"-style #includes are used, the directory of the source being compiled is typically searched prior to other include paths. This means moving source files or introducing new headers can change the files being included, which is almost always undesirable.
- Q: How do I see which optimization flags are enabled with -Ox?
- A: Check the info pages, or use -Q -Ox --help=optimizers.