| #!/bin/bash | |
| # target: squid-openssl 4.13 with listener "http_port 127.0.0.1:3129 tproxy" | |
| # see also: | |
| # https://docs.kernel.org/networking/tproxy.html | |
| # https://blog.cloudflare.com/mmproxy-creative-way-of-preserving-client-ips-in-spectrum/ | |
| # https://latest.gost.run/en/tutorials/redirect/#forwarding-chain_1 | |
| # you might need to enable some iptables/nftables kernel modules: |
The following steps work for all the HTML learning materials on the Learn Rust page:
ebookFormatPreparation.js into your browser's console.
Consistency in naming makes reading and memory retrieval much, much easier. Conversely, changing rules and mixing conventions are very confusing and significantly increase cognitive load. Follow language, company, and project conventions for names, even if you don't like them.
This guide is only for original Ubuntu out-of-the-box packages. If you have added a custom PPA like
pipewire-debian, you might get into conflicts.
Ubuntu 22.04 has PipeWire partially installed and enabled as it's used by browsers (WebRTC) for recoding the screeen under Wayland. We can enable remaining parts and use PipeWire for audio and Bluetooth instead of PulseAudio.
Starting from WirePlumber version 0.4.8 automatic Bluetooth profile switching (e.g. switching from A2DP to HSP/HFP when an application needs microphone access) is supported. Jammy (22.04) repos provide exactly version 0.4.8. So, we're good.
Based on Debian Wiki, but simplified for Ubuntu 22.04.
This is a short post about why I think it would be beneficial for PyTorch to not only use pytest as test runner, but also rely on the other features it provides.
My experience with the PyTorch test suite is limited as of now. Thus, it might very well be that my view on things is too naive. In that case I'm happy to hear about examples where and adoption of pytest would make a use case significantly harder or outright impossible.
| build-container: | |
| stage: build | |
| image: | |
| name: moby/buildkit:rootless | |
| entrypoint: [ "sh", "-c" ] | |
| variables: | |
| BUILDKITD_FLAGS: --oci-worker-no-process-sandbox | |
| before_script: | |
| - | | |
| mkdir ~/.docker |
There are many ways to test Jenkins...
Jenkins Pipeline Unit is great but it's generally recommended to keep all of your logic with stages and not get too crazy with custom Groovy in your pipeline. Though, it's a great option if you have a very advanced use-case and want to make sure your code is reliable.
The Replay Pipeline Run Option is awesome if you want to verify a quick change or iterate quickly on a previously setup pipeline. But it only allows for altering Jenkinsfile Code and runs against the production Jenkins Instance.
| I ran into the battle of running all of my VMs and the host node under a single public IP address. Luckily, the host is just pure Debian, and ships with iptables. | |
| What needs to be done is essentially to run all the VMs on a private internal network. Outbound internet access is done via NAT. Inbound access is via port forwarding. | |
| Network configuration | |
| Here’s how it’s done: | |
| Create a virtual interface that serves as the gateway for your VMs: |
Hosting multiple websites on a single public IP address on the standard HTTP(S) ports is relatively easy with popular web servers like Apache, Nginx and lighttpd all supporting Virtual Hosts.
For Web Services which bundle their own HTTP server, things get more complicated, unless their HTTP stack can be shared somehow. More often than not, the application's HTTP stack listens directly on a dedicated TCP port.
Hosting multiple services on a single IP then requires using a fronting server listening on the standard HTTP port, and routing to the right backend service based on the host name or the path sent by the client.
Path based routing is cumbersome, usually requiring either the service to be aware of the path prefix, or a rewrite by the HTTP fronting server of all absolute URLs in the requests and responses.
Hostname based routing is more straightforward. The fronting server can just look at the [HTTP/1.1 Host header](https://tools
In most of deep learning projects, the training scripts always start with lines to load in data, which can easily take a handful minutes. Only after data ready can start testing my buggy code. It is so frustratingly often that I wait for ten minutes just to find I made a stupid typo, then I have to restart and wait for another ten minutes hoping no other typos are made.
In order to make my life easy, I devote lots of effort to reduce the overhead of I/O loading. Here I list some useful tricks I found and hope they also save you some time.
use Numpy Memmap to load array and say goodbye to HDF5.
I used to relay on HDF5 to read/write data, especially when loading only sub-part of all data. Yet that was before I realized how fast and charming Numpy Memmapfile is. In short, Memmapfile does not load in the whole array at open, and only later "lazily" load in the parts that are required for real operations.
Sometimes I may want to copy the full array to memory at once, as it makes later operations