Welcome to my Technology Hotspot
Tuesday, October 28, 2025
Issue while pasting from the Windows clipboard into a PuTTY vi or vim terminal
Pasting from the Windows clipboard into a PuTTY vi or vim terminal can sometimes be problematic, particularly with newer vim versions that have mouse mode enabled by default. This can lead to unintended visual mode activation or incorrect pasting.
Here are the primary methods to paste from the clipboard into a PuTTY vi/vimsession:
Shift + Right-Click:
Shift + Insert:
Middle Mouse Button (Wheel Click):
Disable vim Mouse Mode (if applicable):
vim Paste Mode:
Note: Ensure vi or vim is in insert mode (by pressing i) before attempting to paste if you want the content to be inserted directly into the file. Otherwise, pasting might be interpreted as vim commands.
For larger pastes, vim's paste mode can be helpful.
Enter insert mode in vim, then type :set paste and press Enter.
Paste your content using one of the methods above, then type :set nopaste and press Enter to exit paste mode.
If you are experiencing issues due to vim's mouse mode, you can disable it for the current session by typing :set mouse= and pressing Enter while in vim.
To make this change permanent, you can add set mouse= to your ~/.vimrc file.
If your mouse has a middle button (often the scroll wheel), clicking it can paste the content.
Shift + Insert:
This keyboard shortcut can also be used to paste the clipboard content.
This is often the most reliable method for pasting in PuTTY, especially when vim's mouse mode is active. Hold down the Shift key and then right-click in the PuTTY window where you want to paste.
Wednesday, October 22, 2025
What caused the AWS outage that broke the internet on Oct 21st 2025
AWS outage 2025: More than 1,000 services were impacted by the outage, including popular platforms like WhatsApp, Snapchat and Reddit, which rely on AWS services, along with financial institutions like the British government’s tax services and entertainment services
In India, the impact of the outage was most pronounced in the aviation sector, with hundreds of flights delayed and several cancelled as airline operators found their systems inoperational and had to switch to manual processes. At least ten banks and NBFCs had “minor disruptions”, which have either been resolved or are being resolved, the Reserve Bank of India said at the time.
Here is a technical explanation for the AWS Outage due to a DNS failure.
AWS's own internal control plane is built on top of DynamoDB. It's a hidden dependency. When AWS's internal services couldn't find the IP for DynamoDB, the entire management layer collapsed.
Stage 1: DNS Fails. The internal DNS servers for dynamodb.us-east-1.amazonaws.com stopped working.
Stage 2: Control Plane Fails. AWS's own services that depend on DynamoDB immediately broke. This included:
IAM (for authentication and session state)
The EC2 instance launch subsystem (which uses DynamoDB for metadata)
Network Load Balancer (NLB) health checks (which, it turns out, write their health state to a DynamoDB table)
Stage 3: Circular Dependency. This is the crazy part. When the NLB health checks failed (because they couldn't write to DynamoDB), it caused more network connectivity issues, which in turn impacted the (already struggling) DynamoDB service itself. It created a vicious feedback loop.
Why it lasted 15+ hours (The UDP problem)
Fixing the DNS issue only took a couple of hours. The reason the recovery took so long was twofold:
The Retry Storm: DNS queries use UDP, which is a stateless, "fire and forget" protocol. When the DNS queries failed, millions of clients (SDKs, Lambda functions, other AWS services) didn't get an immediate "connection refused" (like with TCP). They just timed out after 5+ seconds and then retried. This created a "retry storm" (or thundering herd) of millions of requests that hammered the DNS servers and caches, preventing them from recovering even after the initial fix was in.
The Global Control Plane: Many of AWS's core control plane services (like IAM) are centralized in us-east-1. Even if your app was running in eu-west-1, if it needed to authenticate or launch an instance, that control plane operation was routed through us-east-1 and failed.
AWS's own internal control plane is built on top of DynamoDB. It's a hidden dependency. When AWS's internal services couldn't find the IP for DynamoDB, the entire management layer collapsed.
Stage 1: DNS Fails. The internal DNS servers for dynamodb.us-east-1.amazonaws.com stopped working.
Stage 2: Control Plane Fails. AWS's own services that depend on DynamoDB immediately broke. This included:
IAM (for authentication and session state)
The EC2 instance launch subsystem (which uses DynamoDB for metadata)
Network Load Balancer (NLB) health checks (which, it turns out, write their health state to a DynamoDB table)
Stage 3: Circular Dependency. This is the crazy part. When the NLB health checks failed (because they couldn't write to DynamoDB), it caused more network connectivity issues, which in turn impacted the (already struggling) DynamoDB service itself. It created a vicious feedback loop.
Why it lasted 15+ hours (The UDP problem)
Fixing the DNS issue only took a couple of hours. The reason the recovery took so long was twofold:
The Retry Storm: DNS queries use UDP, which is a stateless, "fire and forget" protocol. When the DNS queries failed, millions of clients (SDKs, Lambda functions, other AWS services) didn't get an immediate "connection refused" (like with TCP). They just timed out after 5+ seconds and then retried. This created a "retry storm" (or thundering herd) of millions of requests that hammered the DNS servers and caches, preventing them from recovering even after the initial fix was in.
The Global Control Plane: Many of AWS's core control plane services (like IAM) are centralized in us-east-1. Even if your app was running in eu-west-1, if it needed to authenticate or launch an instance, that control plane operation was routed through us-east-1 and failed.
Friday, October 10, 2025
How to show hidden folders in Mac OS in Finder
To show hidden files and folders on a Mac, open Finder and press the Command (⌘) + Shift + Period (.) keys simultaneously. The hidden files will appear with a faded or semi-transparent look. To hide them again, press the same keyboard shortcut.
Using the Keyboard Shortcut
- Open any Finder window.
- Navigate to the folder where you want to view hidden files, such as your Macintosh HD folder.
- Press and hold the Command, Shift, and Period keys all at the same time.
- Hidden files and folders will appear.
- To hide them again, repeat the same key combination.
Using Terminal (Alternative Method)
- Open Terminal by searching for it in Spotlight (magnifying glass icon).
- Enter the following command and press Return:
defaults write com.apple.finder AppleShowAllFiles YES. - Hold down the Option key, right-click the Finder icon in the Dock, and select Relaunch to apply the changes.
- To hide all files again, you can use the same command, replacing
YESwithNO, or simply press the keyboard shortcut from the first method.
Why Files Are Hidden
Hidden files are usually system files and should not be deleted or changed as it could cause problems with macOS or specific applications. They are hidden by default to prevent accidental modification or deletion.
Subscribe to:
Comments (Atom)
Featured
TechBytes on Linux
This is a growing list of Linux commands which might come handy for the of Linux users. 1. Found out i had to set the date like this: ...
Popular Posts
-
This is a growing list of Linux commands which might come handy for the of Linux users. 1. Found out i had to set the date like this: ...
-
To set a PDF viewer as the default on Mac OS X: Select any PDF file from Finder. Control-click to open the menu. ... Choose Get...
-
ಮ್ಯಾಕ್ ಬುಕ್ ನಲ್ಲಿ ಕನ್ನಡ ದಲ್ಲಿ ಟೈಪ್ ಮಾಡಲು ಲಿಪಿಕ ಎನ್ನುವ ಈ ಕೆಳಗಿನ ಲಿಂಕ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡಿ .pkg ಫೈಲ್ ಅನ್ನು ಡೌನ್ ಲೋಡ್ ಮಾಡಿ ಅದನ್ನು ಇನ್ಸ್ತಾಲ್ ಮಾಡಿ...