November 29, 2011 developmentNginx
Few days ago I had to add a wordpress installation within the same environment where a Codeigniter app was already running happily and undisturbed.
It took me a while to figure out how to keep separate folders on the filesystem, and serve the blog from a subfolder of the main domain:
| #!/usr/bin/env bash | |
| # This script requires: | |
| # - that the directory $HOME/.mpv exist | |
| # - that the program socat be installed | |
| # - that you start mpv with the unix socket feature pointing at that directory | |
| # I recommend an alias in your .bashrc or equivalent file: | |
| # alias mpv="mpv --input-unix-socket=$HOME/.mpv/socket" | |
| socket="$HOME/.mpv/socket" |
There is an increasing count of applications which use Authy for two-factor authentication. However many users who aren't using Authy, have their own authenticator setup up already and do not wish to use two applications for generating passwords.
Since I use 1Password for all of my password storing/generating needs, I was looking for a solution to use Authy passwords on that. I couldn't find any completely working solutions, however I stumbled upon a gist by Brian Hartvigsen. His post had a neat code with it to generate QR codes (beware, through Google) for you to use on your favorite authenticator.
His method is to extract the secret keys using Authy's Google Chrome app via Developer Tools. If this was not possible, I guess people would be reverse engineering the Android app or something like that. But when I tried that code, nothing appeared on the screen. My gues
| {url:'stun:stun01.sipphone.com'}, | |
| {url:'stun:stun.ekiga.net'}, | |
| {url:'stun:stun.fwdnet.net'}, | |
| {url:'stun:stun.ideasip.com'}, | |
| {url:'stun:stun.iptel.org'}, | |
| {url:'stun:stun.rixtelecom.se'}, | |
| {url:'stun:stun.schlund.de'}, | |
| {url:'stun:stun.l.google.com:19302'}, | |
| {url:'stun:stun1.l.google.com:19302'}, | |
| {url:'stun:stun2.l.google.com:19302'}, |
| TAG-gitrev | TAG | file/version | |
| -----------+------+-------------------------------------------------------------------- | |
| n0.10-0-g7e16636995|n0.10|libavcodec/version.h:#define LIBAVCODEC_VERSION_MAJOR | |
| n0.10-0-g7e16636995|n0.10|libavcodec/version.h:#define LIBAVCODEC_VERSION_MINOR 60 | |
| n0.10-0-g7e16636995|n0.10|libavcodec/version.h:#define LIBAVCODEC_VERSION_MICRO 100 | |
| n0.10-0-g7e16636995|n0.10|libavfilter/version.h:#define LIBAVFILTER_VERSION_MINOR 60 | |
| n0.10-0-g7e16636995|n0.10|libavfilter/version.h:#define LIBAVFILTER_VERSION_MICRO 100 | |
| n0.10-0-g7e16636995|n0.10|libavformat/version.h:#define LIBAVFORMAT_VERSION_MINOR 31 | |
| n0.10-0-g7e16636995|n0.10|libavformat/version.h:#define LIBAVFORMAT_VERSION_MICRO 100 | |
| n0.10.1-0-gd39b183d8d|n0.10.1|libavcodec/version.h:#define LIBAVCODEC_VERSION_MAJOR 53 |
Hello, brethren :-)
As it turns out, the current version of FFmpeg (version 3.1 released earlier today) and libav (master branch) supports full H.264 and HEVC encode in VAAPI on supported hardware that works reliably well to be termed "production-ready".
