Few months ago, I've made a similar work but I wanted something a little more easier to manage. Please have a look at here for my previous work.
This time, I'm gonna do pretty much the same thing but using Pi-hole as base then modify it to include unbound and stubby.
This way, I can use the power of Pi-hole with some additional security layers:
unbound)stubby)
Make sure the if value is correct! If doing this over SSH then open a TMUX session first... or else...
dd if=/dev/YOUR-DEVICE conv=sync,noerror bs=64K | gzip -c > /home/portaj/macbook.img.gz
NOTE: You might not want to compress the image. It just means you have to uncompress it later to mount it. If you're planning to access the data soon, or frequently, don't compress it.
Save it in the same directory as the compressed image so later on if you decide you want to mount or extract data from the image you can see the partition structure without having to decompress the whole image. There might be some other ways to mount a compressed image.
| ## Make a handy json file to automatically install the needed packages for Radarr to run | |
| echo '{"pkgs":["libunwind","icu","libinotify","openssl","mediainfo","sqlite3","ca_root_nss","libiconv","nano","curl","wget"]}' > /tmp/pkg.json | |
| ## Create the jail using that json file we created earlier. | |
| ## I use 12.2-RELEASE as it's the most recent at the time of writing. | |
| ## Replace <IP>, <MASK> and <GATEWAY> with your own. | |
| iocage create -n "radarr" -p /tmp/pkg.json -r 12.2-RELEASE ip4_addr="vnet0|<IP>/<MASK>" defaultrouter="<GATEWAY>" vnet="on" allow_mlock="1" allow_raw_sockets="1" boot="on" | |
| ## Delete the now useless file we created at the beginning. | |
| rm /tmp/pkg.json |
This explains how to build mesa from source, and how to use the custom built mesa to run some apps and games, without needing to replace the mesa libraries that your operating system runs on.
Let's assume that you are using an x86_64 system.
| 10-Bit H.264 | |
| For all those who haven’t heard of it already, here’s a quick rundown about the | |
| newest trend in making our encodes unplayable on even more systems: So-called | |
| high-bit-depth H.264. So, why another format, and what makes this stuff | |
| different from what you know already? | |
| First off: What is bit depth? | |
| In short, bit depth is the level of precision that’s available for storing color | |
| information. The encodes you’re used to have a precision of 8 bits (256 levels) |
This is a list of general-purpose optimizations for C programs, from the most impactful to the tiniest low-level micro-optimizations to squeeze out every last bit of performance. It is meant to be read top-down as a checklist, with each item being a potential optimization to consider. Everything is in order of speed gain.
Choose the best algorithm and data structure for the problem at hand by evaluating:
Europe
#Notes this is a fork from GMK87 adapted to gmk87, if you notice something wrong or add any other feature, just ping me here on github.
English manual for the ZUOYA GMK87 Mechanical Keyboard. Made from the printed version (Original).
See how a minor change to your commit message style can make a difference.
Tip
Take a look at git-conventional-commits , a CLI util to ensure these conventions, determine version and generate changelogs
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".