| # Chapter 1: immediate evaluation with optional composition | |
| @lambda f: not f() | |
| def true() -> bool: | |
| return False | |
| assert true == True # ??? | |
| # Chapter 2: single line composition |
| addEventListener('fetch', event => { | |
| event.respondWith(handleRequest(event.request)) | |
| }) | |
| async function handleRequest(request) { | |
| const url = new URL(request.url) | |
| // Check if the path starts with /blog | |
| if (url.pathname.startsWith('/blog')) { | |
| const subPath = url.pathname.replace('/blog', '') | |
| const githubUrl = new URL(`SOURCE_URL${subPath}`) |
This guide is for homelab admins who understand IPv4s well but find setting up IPv6 hard or annoying because things work differently. In some ways, managing an IPv6 network can be simpler than IPv4, one just needs to learn some new concepts and discard some old ones.
Let’s begin.
First of all, there are some concepts that one must unlearn from ipv4:
Concept 1
| # The following is a guide for debian 12 (bookworm), it should work on all modern distros and the concepts will apply to any OS of your choosing | |
| # What this will do is create a dual-stack (so ipv4 and ipv6) docker network you can add to your containers and add NAT for this network so any requests are mapped to a random IP from the specified range | |
| # NOTE: Due to how linux does SNAT (source: http://blog.asiantuntijakaveri.fi/2017/03/linux-snat-with-per-connection-source.html) the outgoing ip SNAT picks is "sticky", linux hashes the source ip and uses that to pick the outgoing IP, in the usual /64 setup it seems to switch between 2 outgoing ips | |
| # The blog post links a kernel patch to change this, but I don't want to get into patching the kernel (here, or at all to be honest). | |
| # I have thought of a workaround to try, adding many SNAT rules with a sub-set of the ip range for each source port (as those should be random), then you'd get ~40k (rough untested guesstimate) ips per container, but I don't kno |
Inspired by this
More of my guides: Debloating MEMu - Debloating Nox (Updated)
This mainly applies to LDPlayer9. They will probably work on the low end options (like LDPlayer5) but not guaranteed.
This emulator seems to have less stability issues than MEMu. I think we get the shtick that these emulators do spooky stuff.
Inspired by this
More of my guides: Debloating LDPlayer - Debloating Nox (Updated)
Edit 22/8/2021: I have updated MEmu and it seems like it reinstalls the apps and re-enables the services. Repeat steps 5, 7, 8, and 9 if you update MEmu.
In my experience, Nox can be quite slow and choppy, and looks like I'm not the only person with this problem. A lot of people say that MEmu performs better than Nox, and I could agree with that. I have no chopping issues with it so far. But like Nox, there are kinda shady stuff going on.
Note: This gist may be outdated, thanks to all contributors in comments.
adb is the Android CLI tool with which you can interact with your android device, from your PC
You must enable developer mode (tap 7 times on the build version in parameters) and install adb on your PC.
Don't hesitate to read comments, there is useful tips, thanks guys for this !
You can see my latest update in my blog here https://medium.com/@calvin.hsieh/steps-to-install-mongodb-on-aws-ec2-instance-62db66981218
Credits:
Big thanks to Elad Nava and Shane Rainville for writing the above articles that allow me to conduct this guide. If by all means that I violated original post's copyright, please contact me.
| # download from http://sourceforge.net/projects/aria2/files/stable/aria2-1.19.0 | |
| sudo yum install gcc-g++ openssl-devel -y | |
| tar xvfj aria2...tar.bz2 | |
| ./configure | |
| make -j$(nproc) | |
| sudo make install |
| #include <unistd.h> | |
| #include <mach/mach.h> | |
| #include <mach/mach_vm.h> | |
| #include <mach-o/dyld.h> | |
| int | |
| main (int argc, char * argv[]) | |
| { | |
| volatile char * library; | |
| const mach_vm_size_t page_size = getpagesize (); |
