| #!/bin/bash | |
| # Colors | |
| RED='\033[0;31m' | |
| GREEN='\033[0;32m' | |
| NO_COLOR='\033[0m' | |
| BLUE='\033[0;34m' | |
| YELLOW='\033[0;33m' | |
| NO_COLOR='\033[0m' |
| #!/usr/bin/env python2 | |
| import requests | |
| from tqdm import tqdm | |
| import re | |
| import os | |
| def download_file_from_google_drive(id, destination): | |
| URL = 'https://docs.google.com/uc?export=download' | |
| session = requests.Session() |
xhost + ${hostname} to allow connections to the macOS host *export HOSTNAME=`hostname`* environment:
| # Instructions for 4.14 and cuda 9.1 | |
| # If upgrading from 4.13 and cuda 9.0 | |
| $ sudo apt-get purge --auto-remove libcud* | |
| $ sudo apt-get purge --auto-remove cuda* | |
| $ sudo apt-get purge --auto-remove nvidia* | |
| # also remove the container directory direcotory at /usr/local/cuda-9.0/ | |
| # Important libs required with 4.14.x with Cuda 9.X | |
| $ sudo apt install libelf1 libelf-dev |
Flame graphs are a nifty debugging tool to determine where CPU time is being spent. Using the Java Flight recorder, you can do this for Java processes without adding significant runtime overhead.
Shivaram Venkataraman and I have found these flame recordings to be useful for diagnosing coarse-grained performance problems. We started using them at the suggestion of Josh Rosen, who quickly made one for the Spark scheduler when we were talking to him about why the scheduler caps out at a throughput of a few thousand tasks per second. Josh generated a graph similar to the one below, which illustrates that a significant amount of time is spent in serialization (if you click in the top right hand corner and search for "serialize", you can see that 78.6% of the sampled CPU time was spent in serialization). We used this insight to spee
The root filesystem is rootfs, which is stored in memory and therefore wiped on reboot. The Micro SD card is mounted at /tmp/fuse_d/. Something is also mounted at /tmp/fuse_a and /tmp/fuse_z.
| # In order for gpg to find gpg-agent, gpg-agent must be running, and there must be an env | |
| # variable pointing GPG to the gpg-agent socket. This little script, which must be sourced | |
| # in your shell's init script (ie, .bash_profile, .zshrc, whatever), will either start | |
| # gpg-agent or set up the GPG_AGENT_INFO variable if it's already running. | |
| # Add the following to your shell init to set up gpg-agent automatically for every shell | |
| if [ -f ~/.gnupg/.gpg-agent-info ] && [ -n "$(pgrep gpg-agent)" ]; then | |
| source ~/.gnupg/.gpg-agent-info | |
| export GPG_AGENT_INFO | |
| else |
| # <type>: (If applied, this commit will...) <subject> (Max 50 char) | |
| # |<---- Using a Maximum Of 50 Characters ---->| | |
| # Explain why this change is being made | |
| # |<---- Try To Limit Each Line to a Maximum Of 72 Characters ---->| | |
| # Provide links or keys to any relevant tickets, articles or other resources | |
| # Example: Github issue #23 |
| # Type(<scope>): <subject> | |
| # <body> | |
| # <footer> | |
| # Type should be one of the following: | |
| # * feat (new feature) | |
| # * fix (bug fix) | |
| # * docs (changes to documentation) |
| for WID in `xwininfo -root -tree | sed '/"plasma-desktop": ("Plasma" "Plasma")/!d; s/^ *\([^ ]*\) .*/\1/g'`; do | |
| xprop -id $WID -remove _KDE_NET_WM_SHADOW | |
| done | |
| # or | |
| for WID in `xwininfo -root -tree | sed '/"Plasma": ("plasmashell" "plasmashell")/!d; s/^ *\([^ ]*\) .*/\1/g'`; do | |
| xprop -id $WID -remove _KDE_NET_WM_SHADOW | |
| done |