In this article, I will share some of my experience on installing NVIDIA driver and CUDA on Linux OS. Here I mainly use Ubuntu as example. Comments for CentOS/Fedora are also provided as much as I can.
;; based on http://emacsredux.com/blog/2013/04/03/delete-file-and-buffer/ | |
(defun delete-file-and-buffer () | |
"Kill the current buffer and deletes the file it is visiting." | |
(interactive) | |
(let ((filename (buffer-file-name))) | |
(if filename | |
(if (y-or-n-p (concat "Do you really want to delete file " filename " ?")) | |
(progn | |
(delete-file filename) | |
(message "Deleted file %s." filename) |
#!/usr/bin/env bash | |
# 'Wi-Fi' or 'Ethernet' or 'Display Ethernet' | |
INTERFACE=Wi-Fi | |
# Ask for the administrator password upfront | |
sudo -v | |
# Keep-alive: update existing `sudo` time stamp until finished | |
while true; do sudo -n true; sleep 60; kill -0 "$$" || exit; done 2>/dev/null & |
### | |
### | |
### UPDATE: For Win 11, I recommend using this tool in place of this script: | |
### https://christitus.com/windows-tool/ | |
### https://github.com/ChrisTitusTech/winutil | |
### https://www.youtube.com/watch?v=6UQZ5oQg8XA | |
### iwr -useb https://christitus.com/win | iex | |
### | |
### |
#!/bin/bash | |
#Make sure we’re running with root permissions. | |
if [ `whoami` != root ]; then | |
echo Please run this script using sudo | |
echo Just type “sudo !!” | |
exit | |
fi | |
#Check for 64-bit arch | |
if [uname -m != x86_64]; then |
import argparse | |
import sys | |
from tensorflow.examples.tutorials.mnist import input_data | |
from time import time | |
t0 = time() | |
import tensorflow as tf | |
tf.summary.FileWriterCache.clear() |
tl;dr:
$ iex --sname server
$ iex --sname client
iex(client@localhost)> Node.connect :"server@localhost"
Start a named node:
$ iex --name any_name@any_domain
This gist is based on the information available at golang/dep, only slightly more terse and annotated with a few notes and links primarily for my own personal benefit. It's public in case this information is helpful to anyone else as well.
I initially advocated Glide for my team and then, more recently, vndr. I've also taken the approach of exerting direct control over what goes into vendor/
in my Dockerfiles, and also work from
isolated GOPATH environments on my system per project to ensure that dependencies are explicitly found under vendor/
.
At the end of the day, vendoring (and committing vendor/
) is about being in control of your dependencies and being able to achieve reproducible builds. While you can achieve this manually, things that are nice to have in a vendoring tool include:
a4b.amazonaws.com | |
access-analyzer.amazonaws.com | |
account.amazonaws.com | |
acm-pca.amazonaws.com | |
acm.amazonaws.com | |
airflow-env.amazonaws.com | |
airflow.amazonaws.com | |
alexa-appkit.amazon.com | |
alexa-connectedhome.amazon.com | |
amazonmq.amazonaws.com |
image: docker:latest | |
variables: | |
REPOSITORY_URL: <AWS ACCOUNT ID>.dkr.ecr.eu-central-1.amazonaws.com/<ECS REPOSITORY NAME> | |
REGION: eu-central-1 | |
TASK_DEFINTION_NAME: <TASK DEFINITION NAME> | |
CLUSTER_NAME: <CLUSTER NAME> | |
SERVICE_NAME: <SERVICE NAME> | |
services: |