- Add your project logo.
- Write a short introduction to the project.
- If you are using badges, add them here.
| aws-profile() { | |
| read -r -d '' SCRIPT <<'EOF' | |
| import argparse | |
| from configparser import RawConfigParser | |
| import os | |
| import shutil | |
| import subprocess | |
| import sys | |
| from textwrap import dedent |
| package main | |
| import ( | |
| "fmt" | |
| pkgerr "github.com/pkg/errors" | |
| ) | |
| func main() { | |
| if err := foo(); err != nil { |
| package main | |
| import ( | |
| "context" | |
| "fmt" | |
| "math/rand" | |
| "os" | |
| "time" | |
| ) |
| var x string | |
| var l int | |
| func same(i, l int, x string) bool { | |
| j = i - l | |
| for k := 0 ; k < l; k ++ { | |
| // rune | |
| if x[i-k] != x[j-k] { | |
| return false | |
| } | |
| } |
I liked the way Grokking the coding interview organized problems into learnable patterns. However, the course is expensive and the majority of the time the problems are copy-pasted from leetcode. As the explanations on leetcode are usually just as good, the course really boils down to being a glorified curated list of leetcode problems.
So below I made a list of leetcode problems that are as close to grokking problems as possible.
| # one or the other, NOT both | |
| [url "https://github"] | |
| insteadOf = git://github | |
| # or | |
| [url "[email protected]:"] | |
| insteadOf = git://github |
| #!/bin/bash | |
| # https://cloud.google.com/compute/docs/faq#find_ip_range | |
| # nslookup -q=TXT _cloud-netblocks.googleusercontent.com 8.8.8.8 | |
| myarray=() | |
| for LINE in `dig txt _cloud-netblocks.googleusercontent.com +short | tr " " "\n" | grep include | cut -f 2 -d :` | |
| do | |
| myarray+=($LINE) | |
| for LINE2 in `dig txt $LINE +short | tr " " "\n" | grep include | cut -f 2 -d :` |
Geth (Go-Ethereum) as of July 2022 takes about 650 GiB of space on a fast/snap sync, and then grows by ~ 14 GiB/week with default cache, ~ 8 GiB/week with more cache.
This will fill a 1TB SSD in a few months, to the point where space usage should be brought down again with an offline prune.
There is an odd behavior with Geth 1.10.20 where initial DB size is large after sync until Geth has been restarted twice. This is expected to be fixed soon, possibly as soon as 1.10.21.
Happily, Geth 1.10.x introduces "snapshot offline prune", which brings it back down to about its original size. It takes roughly 4-6 hours to prune the Geth database, and this has to be done while Geth is not running.
Caveat that while several folx have used offline pruning successfully, there is risk associated with it. The two failure mode
Geth, and other execution clients such as Erigon, Nethermind, and Besu, take some time on shutdown to cleanly close their database. When not given that time, they will need to resync upon restart, often for hours. This gist describes the systemd service file parameter to give them up to 5 minutes of time for a clean shutdown.
- Find your service file. It may be called
/etc/systemd/system/geth.serviceor/etc/systemd/system/eth1.service. - Edit it using
sudo nano FILENAME, and addTimeoutStopSec=300to the[Service]section. Here is an example of a service file after the change: