| ||youtube.com$domain=~youtube.com # Don't pull youtube JS unless you're using youtube. This breaks | |
| # embedded videos, which is mildly inconvenient, but makes everything else in the world much, much faster. | |
| # This blocks a lot of Google everywhere but Google. | |
| ||www.gstatic.com$domain=~google.com|~google | |
| ||gstatic.com$domain=~google.com|~google # Don't use gstatic unless you're on Google. This might | |
| # break some things but so far I haven't noticed any problems. | |
| ||accounts.google.com$domain=~google.com|~google # Don't pop up the "log in with google" dialog everywhere. This makes the | |
| # internet feel about 95% less creepy. |
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 code for my article with the same name. You can find it at the URL below: | |
| # https://www.mvanga.com/blog/basic-music-theory-in-200-lines-of-python | |
| # MIT License | |
| # | |
| # Copyright (c) 2021 Manohar Vanga | |
| # | |
| # Permission is hereby granted, free of charge, to any person obtaining a copy | |
| # of this software and associated documentation files (the "Software"), to deal | |
| # in the Software without restriction, including without limitation the rights |
The user experience of Python on a minimal Debian or Ubuntu installation is bad. Core features like virtual environments, pip bootstrapping, and the ssl module are either missing or do not work like designed and documented. Some Python core developers including me are worried and consider Debian/Ubuntu's packaging harmful for Python's reputation and branding. Users don't get what they expect.
The problems can be easily reproduced with official Debian and Ubuntu containers in Docker or Podman. Debian Stable (Debian 10 Buster) comes with Python 3.7.3. Ubuntu Focal (20.04 LTS) has Python 3.8.5.
| Mute these words in your settings here: https://twitter.com/settings/muted_keywords | |
| ActivityTweet | |
| generic_activity_highlights | |
| generic_activity_momentsbreaking | |
| RankedOrganicTweet | |
| suggest_activity | |
| suggest_activity_feed | |
| suggest_activity_highlights | |
| suggest_activity_tweet |
The always enthusiastic and knowledgeable mr. @jasaltvik shared with our team an article on writing (good) Git commit messages: How to Write a Git Commit Message. This excellent article explains why good Git commit messages are important, and explains what constitutes a good commit message. I wholeheartedly agree with what @cbeams writes in his article. (Have you read it yet? If not, go read it now. I'll wait.) It's sensible stuff. So I decided to start following the
| # /etc/profile.d/best_bash_history.sh | |
| # Save 5,000 lines of history in memory | |
| HISTSIZE=10000 | |
| # Save 2,000,000 lines of history to disk (will have to grep ~/.bash_history for full listing) | |
| HISTFILESIZE=2000000 | |
| # Append to history instead of overwrite | |
| shopt -s histappend | |
| # Ignore redundant or space commands | |
| HISTCONTROL=ignoreboth | |
| # Ignore more |
If you work across many computers (and even otherwise!), it's a good idea to keep a copy of your setup on the cloud, preferably in a git repository, and clone it on another machine when you need.
Thus, you should keep the .vim directory along with your .vimrc version-controlled.
But when you have plugins installed inside .vim/bundle (if you use pathogen), or inside .vim/pack (if you use Vim 8's packages), keeping a copy where you want to be able to update the plugins (individual git repositories), as well as your vim-configuration as a whole, requires you to use git submodules.
Initialize a git repository inside your .vim directory, add everything (including the vimrc), commit and push to a GitHub/BitBucket/GitLab repository:
cd ~/.vim
| # Install tmux on rhel/centos 7 | |
| # install deps | |
| yum install gcc kernel-devel make ncurses-devel | |
| # DOWNLOAD SOURCES FOR LIBEVENT AND MAKE AND INSTALL | |
| curl -OL https://github.com/libevent/libevent/releases/download/release-2.0.22-stable/libevent-2.0.22-stable.tar.gz | |
| tar -xvzf libevent-2.0.22-stable.tar.gz | |
| cd libevent-2.0.22-stable | |
| ./configure --prefix=/usr/local |
I do not work for Coinbase and do not in any way speak for or represent them. This post was hastily written and is probably full of typos!
This is my attempt to clarify the possibilities that might be going on, based on various Coinbase employee statements.
First, I should highlight that there has been a good amount of confusion created by the replay attacks going on between the "two" Ethereum chains. So much so that it seems to have confused just about everyone, including me, as to the details of what's going on with Coinbase's ETH/ETC (and other ETH/ETC).
I put "two" in quotes because at the moment it's more like there are "1.25 Ethereum chains" because of the replay attacks, which are causing almost every transaction to get mirrored on the other chain. Replay attacks are possible because Ethereum's hard fork did not take steps to make Ethereum transactions invalid on the original chain. Instead, all transactions are valid on both chains unless specia