Don’t get me wrong. I love FSD. It is one of the most exciting consumer experiences in the recent years. Last such excitement for me probably goes back more than 10 years when I first put my hand on Apple iPhone 2. For me, FSD changes the perception of distance and mobility. It makes San Francisco symphony concert much more enjoyable than ever.
That said, I still have a lot of complaints of today’s FSD.
Too many unnecessary accelerations, many of which are followed by consequential breakings, which means more discomfort. Note I chose “Chill” profile. Otherwise it is probably even worse.
Acceleration is often too aggressive, especially for local driving. Why so? saving time? There are many other wasted opportunities for saving time. No need to focus on the acceleration aspect.
Phantom breaking, i.e., breaking for no obvious reasons. (discomfort and wasting time)
Non-human breaking pattern, which often breaks too hard at beginning and then, realizing it, relax the breaking. Human often breaks soft, and then, realizing not enough, start to break harder (discomfort)
Don’t remember routine route road conditions. Every road has its own quirks. It is OK for Tesla to be cautious when seeing those quirk if it sees for the first time. However, it does not remember those quirks and repeating driving always feels like first-timer driving on those roads. Human tend to be more relaxed (and thus more smooth) on later repeated driving.
Map sucks and don’t remember my corrections. This is especially annoying for routine routes.
Can’t back to my garage, which is the only way I can charge my Tesla today.
Alpine Linux is a popular choice for building docker. Since v3.17, leveldb version is bumped from v1.22 to v1.23, where the new version disabled rtti, which caused many packages to break, including popular python module, plyvel. I encountered this problem when building electrumX docker image. Googling around I realize this is a popular problem and there are no easy and obvious solutions.
I decided to simply build apk files for leveldb v1.22 against the latest alpine linux, which is 3.20 today.
Check out aports at alpine version v3.16, (host) git clone –depth=1 https://gitlab.alpinelinux.org/alpine/aports -b 3.16-stable aports-3.16
Copy over leveldb APKBUILD file over to the latest 3.20 aports, (host) cp -a aports-3.16/main/leveldb aports/main/
go back to alpine-dev container and build the package files
(alpine-dev) cd ~/aports/main/leveldb
(alpine-dev) abuild -r
The file APK files are located under ~/packages/main/x86_64. For convenience, I have include those two files below. Of course, you should strip the “.bin” suffix before using them. I had to add the suffix to work around wordpress restrictions. Please refer to this docker file to see how these files are used in a real case.
I was running UmbrelOS on Raspberry Pi, with an external 2TB SSD disk. The machine is obviously under powered and started to show weakness. So I decided to migrate to a Lenovo mini-PC, M710q.
I need to re-use the same the SSD disk because M710q doesn’t have enough storage by itself (500GB). Ideally I can keep all the blockchain data and setup, so that I don’t have re-sync everything and re-setup everything.
While this may sound like a common question, I did not find many answers on the internet. The closest one is this one. However, UmbrelOS is currently at v1.x. A lot of don’t apply anymore.
Below is how I did it.
Prepare SSD disk
Upgrade Raspberry Pi to the latest UmbrelOS v1.1.
Shut it down via Umbrel Settings and unplug SSD disk.
cd /home/umbrel; mv umbrel umbrel.bak; ln -s /mnt/umbrel-ssd/umbrel umbrel
sudo systemctl start umbrel
It will take a long to re-start umbrel since it will fetch various containers etc. But it will use the same blockchain and other app-specific settings you had before on SSD disk. After a couple of coffee time, you will be all set!
TailScale is great VPN. It is even greater if it runs all the time on a router! Currently it is available as 3rd party package for Synology NAS (X64-based) machines, but not for Routers (usually ARM64-based). *sigh* This blog talks about a way to set it up.
Untar or unzip the package a couple of times and extract two binary files, tailscale and tailscaled. See pictures below.
Copy (scp) over these two files to Synology router, say under your home directory’s subdirectory, “tailscale”.
Testing
Download the script that starts/stops the tailscale daemon
This script is derived from TailScale’s original script and is adapted to SRM environment
MODIFY SCRIPT with your own path for PKGVAR variable
Now type “./start-stop-status start” and “./start-stop-status status”
For the first time running, type “./tailscale –socket tailscaled.sock up –advertise-exit-node” and perform web-based login/setup. See my previous post.
Start up TailScale automatically
Copy the start-stop-status script to /usr/local/etc/rc.d/ directory
It’s pretty stupid and annoying (maybe intentional?) that AWS provides DNS service (Route 53) but does not provide dynamic DNS to its own instances!!! This blog describes a method to achieve just that with various AWS features, namely EC2 instance events, Lambda functions and Route 53.
Specifically,
You must already host some domains with Route 53
You like to launch EC2 instances with public IP addresses
You like to assign some cool domain names to those EC2 instances, automatically
When those instances are stopped, you like those domain names are removed automatically
I have done this for over 5 or 6 years now. The blog is an attempt to capture what I did and keep my memory fresh! The approach was based on some early articles, most likely an early version of this one. However, I spent time to develop my own version which has diverged significantly now. For example, my version supports multiple domains and doesn’t use database. Also my blog will focus on using AWS console operations instead of using CLI.
Usage
Suppose you own a domain called mydomain.com and you are hosting it with Route 53. When you launch an EC2 instance, you can set the name tag as “ddns-fun.mydomain.com” during launch or startup time. See pictures below. After the instance starts running, you will automatically have a A-type DNS record “fun.mydomain.com” pointing to the instance’s IP address.
During EC2 launch
After EC2 launch
When you stop or terminate the instance, the DNS record will be removed automatically.
Overview of the process
It is relatively complicated. Below is an overview.
The central piece is a lambda function written in Python 3.x called ddns_lambda. This function will receive events when EC2 instances are started or stopped. It will examine the name tag or DNS records to determine whether it should add some DNS records or remove them.
In order for the ddns_lambda to run with right permissions and access the recourses, you will create an IAM policy, called ddns-lambda-policy and an IAM role, called ddns-lambda-role.
Lastly you will create an event triggering rule that monitors EC2 instance start/stop. When such event happens, ddns_lambda function will be called.
Let us dive in!
Create a policy for DDNS lambda role
Go to AWS/Services/IAM/Policies
Click on “Create policy” on the top-right
On “Specify permissions” page, choose JSON option and enters following code. The policy allows access to ec2 instance query, write logs, and full access to route53.