| # put this in your .bash_profile | |
| if [ $ITERM_SESSION_ID ]; then | |
| export PROMPT_COMMAND='echo -ne "\033];${PWD##*/}\007"; ':"$PROMPT_COMMAND"; | |
| fi | |
| # Piece-by-Piece Explanation: | |
| # the if condition makes sure we only screw with $PROMPT_COMMAND if we're in an iTerm environment | |
| # iTerm happens to give each session a unique $ITERM_SESSION_ID we can use, $ITERM_PROFILE is an option too | |
| # the $PROMPT_COMMAND environment variable is executed every time a command is run | |
| # see: ss64.com/bash/syntax-prompt.html |
| #!/usr/bin/ruby | |
| # Create display override file to force Mac OS X to use RGB mode for Display | |
| # see http://embdev.net/topic/284710 | |
| require 'base64' | |
| data=`ioreg -l -d0 -w 0 -r -c AppleDisplay` | |
| edids=data.scan(/IODisplayEDID.*?<([a-z0-9]+)>/i).flatten | |
| vendorids=data.scan(/DisplayVendorID.*?([0-9]+)/i).flatten |
The Macbook Pro 11,3 (late 2013, Retina) is equipped with two GPUs:
Currently under Linux the Intel GPU can only be used with the help of:
If your custom iso is not mounting, and your console is at an iPXE shell, you can:
initrd http://mfsbsd.vx.sk/files/iso/10/amd64/mfsbsd-se-10.1-RELEASE-amd64.iso
While the iso is downloading, vultr's iPXE does not include memdisk, so we have to upload it ourselves to another host.
Here's one I found public, though I wouldn't recommend using it: http://preseed.panticz.de/ipxe/memdisk
| #include <sys/socket.h> | |
| #include <sys/ioctl.h> | |
| #include <sys/kern_event.h> | |
| #include <stdio.h> | |
| #include <stdint.h> | |
| #include <stdbool.h> | |
| #include <stdlib.h> | |
| #include <assert.h> | |
| #include <string.h> | |
| #include <net/ethernet.h> |
| #!/usr/bin/env python | |
| """ | |
| Script for dumping Bluetooth pairings from OS X to a registry file, for Windows | |
| import. This will allow you to have your Bluetooth devices paired with both | |
| operating systems at the same time. | |
| In case of problems with Windows registry entries: pair your device with Windows | |
| first, then with OS X, and then do the dump and import. | |
| Latest version can be found at: |
Short version: I strongly do not recommend using any of these providers. You are, of course, free to use whatever you like. My TL;DR advice: Roll your own and use Algo or Streisand. For messaging & voice, use Signal. For increased anonymity, use Tor for desktop (though recognize that doing so may actually put you at greater risk), and Onion Browser for mobile.
This mini-rant came on the heels of an interesting twitter discussion: https://twitter.com/kennwhite/status/591074055018582016
| OS X Yosemite Kernel Debug Kit Read Me | |
| Please Note: After installation, the Kernel Debug Kit will be available at: | |
| /Library/Developer/KDKs/ | |
| ——————————————————————————————— | |
| The kernel file location has changed. | |
| The kernel file location has moved to /System/Library/Kernels/kernel | |
| DEVELOPMENT and DEBUG kernels | |
| The OS X Yosemite Kernel Debug Kit includes the DEVELOPMENT and DEBUG kernel builds. These both have additional assertions and error checking compared to the RELEASE kernel. The DEVELOPMENT kernel can be used for every-day use and has minimal performance overhead, while the DEBUG kernel has much more error checking. | |
| this[([]+!![])[!![]+!![]+!![]]+"v"+([]+![])[![]+!![]]+([]+![])[!![]+!![]]](([]+![])[![]+![]]+([]+[][[]])[![]+![]]+([]+[][[]])[![]+!![]]+([]+typeof([]))[!![]+!![]+!![]+!![]]+([]+!![])[![]+![]]+([]+[][[]])[!![]+!![]+!![]+!![]+!![]]+([]+typeof([]))[![]+![]]+([]+[][[]])[![]+!![]]+" "+([]+![])[![]+!![]]+([]+!![])[![]+!![]]+([]+!![])[![]+!![]]+([]+![])[![]+!![]]+"y"+([]+[][[]])[!![]+!![]+!![]+!![]+!![]]+([]+![])[![]+![]]+"y"+"("+([]+!![])[![]+![]]+")"+"{"+"v"+([]+![])[![]+!![]]+([]+!![])[![]+!![]]+" "+([]+typeof([]))[![]+![]]+"="+"{"+([]+![])[![]+!![]]+":"+"\""+"("+"["+"]"+"+"+"!"+"["+"]"+")"+"["+"!"+"["+"]"+"+"+"!"+"!"+"["+"]"+"]"+"\""+","+(typeof(![]))[![]+![]]+":"+"\""+"("+([]+!![])[![]+![]]+"y"+"p"+([]+!![])[!![]+!![]+!![]]+([]+typeof([]))[![]+![]]+([]+![])[![]+![]]+"("+"!"+"["+"]"+")"+")"+"["+"!"+"["+"]"+"+"+"!"+"["+"]"+"]"+"\""+","+([]+typeof([]))[!![]+!![]+!![]+!![]]+":"+"\""+"("+"["+"]"+"+"+([]+!![])[![]+![]]+"y"+"p"+([]+!![])[!![]+!![]+!![]]+([]+typeof([]))[![]+![]]+([]+![])[![]+![]]+"("+"["+"]"+")"+")"+"[ |
| commit 3f5e3bdbb45bc2cd9ae95972420eb11b0340f120 | |
| Author: Matthew Garrett <mjg59@coreos.com> | |
| Date: Mon Feb 1 13:31:00 2016 +1100 | |
| Block most UEFI variable deletions | |
| Some systems appear to become upset if certain UEFI non-volatile variables | |
| are delted, to the point of no longer POSTing successfully. For a short-term | |
| fix, let's just block deletion of most variables while we figure out a | |
| better approach. |