Skip to content

Instantly share code, notes, and snippets.

View andy108369's full-sized avatar
🎯
Focusing

Andrey Arapov andy108369

🎯
Focusing
View GitHub Profile
@andy108369
andy108369 / README.md
Created October 21, 2024 19:11 — forked from yorickdowne/README.md
Ubuntu Desktop 20.04 with mirrored ZFS boot drive

Ubuntu 24.04

From the comments: "These exact instructions are not working on Ubuntu 24.04. Ubuntu has changed the naming of ZFS partitions, partition 2 and 3 are switched around, and the boot/efi folder is now different."

I don't have my dual-disk test system any longer, and so can't adjust these steps myself.

Overview

Ubuntu Desktop 20.04 supports a single ZFS boot drive out of the box. I wanted a ZFS mirror, without going through an entirely manual setup of Ubuntu as described by OpenZFS in their instructions for Ubuntu 20.04 and instructions for Ubuntu 22.04

@andy108369
andy108369 / reload-nvidia-module-k8s.md
Last active August 10, 2024 12:57
Steps to reload the nvidia kernel module in K8s env

Steps to reload the nvidia kernel module in K8s env

Unload nvidia driver

NOTE: You can only do this if there is no GPU deployments actively using GPU on the node.

# Cordoning the node will automatically terminate the `nvdp-nvidia-device-plugin-#####` pod on it. This does not impact already running non-GPU deployments on that node.
kubectl cordon node7

GPU PCIe passthrough with Proxmox

  1. Read these docs first to understand the passthrough subject better

We are using the GPU Seabios PCI Express Passthrough method. There's no significant difference in GPU performance between SeaBIOS and OVMF for GPU passthrough. The choice mainly affects the boot process and compatibility. Once the OS is loaded, GPU performance is similar for both. OVMF is generally recommended for better compatibility and modern hardware support.

@andy108369
andy108369 / RFASM.md
Last active April 23, 2024 15:05
Reverse Fee Adjustment Mechanism with Spam Mitigation (RFASM) - A Proposal for Sustaining Miner Incentive

Reverse Fee Adjustment Mechanism with Spam Mitigation (RFASM) - A Proposal for Sustaining Miner Incentive

Abstract:

In the evolving landscape of Kaspa's mining economics, there is a pivotal need to ensure continuous miner incentive as block rewards phase out. With an emphasis on preserving Kaspa's competitive low-fee advantage, the Reverse Fee Adjustment Mechanism with Spam Mitigation (RFASM) proposal introduces a dynamic yet robust fee structure to align network security and usability.

Proposal:

The RFASM integrates a dynamic fee algorithm with anti-spam safeguards, operating under these principles:

  1. Reverse Fee Adjustment: Fees adjust inversely with network activity—increasing during low activity for miner incentive, decreasing during high activity to maintain user engagement.
@andy108369
andy108369 / utxo-consolidation-tangem-wallet.md
Last active February 8, 2024 16:43
Managing UTXO Consolidation with Tangem Wallet: A Focus on UTXO-Based Blockchains

Managing UTXO Consolidation with Tangem Wallet: A Focus on UTXO-Based Blockchains

In the realm of cryptocurrency, managing assets efficiently is crucial for users leveraging hardware wallets, such as Tangem. A significant aspect of this management involves understanding and navigating the intricacies of unspent transaction outputs (UTXOs), a concept inherent to UTXO-based blockchains. This discussion is particularly pertinent to users engaging with cryptocurrencies like Bitcoin (BTC), Kaspa (KAS), and other prominent UTXO-based currencies supported by the Tangem App.

UTXO-Based Blockchains: The Basics

UTXO-based blockchains, such as Bitcoin (BTC), Kaspa (KAS), Litecoin (LTC), and Bitcoin Cash (BCH), function by tracking transactions through outputs that have been generated by previous transactions and not yet spent. Each transaction starts with inputs (UTXOs from previous transactions) and ends with outputs (new UTXOs). The accumulation of UTXOs at a single address necessitates effective management

# https://gist.github.com/andy108369/ef23ff0fe5caf2e12b1b41a99e812294
# Last updated on June 06 2023 16:25
#
# PoC SDL for running nym-mixnode on Akash Network
# https://twitter.com/andy83482/status/1665093815290437635
#
# Provider requires to support the IPv6, steps outlined here https://github.com/akash-network/support/issues/100
#
# apt update
# apt -y install wget curl jq iproute2 iputils-ping net-tools netcat-openbsd

Building docker images in an unprivileged container

This is a PoC only! Use official Kaniko docker image!

WARNING

DESTRUCTIVE!

Running Kaniko (built from the sources) erases the user from /etc/passwd upon execution. Likely to destroy the container too, depending on what's in the Dockerfile. There might be a better isolated way of running it, but I recommend using the official Kaniko container.

Moved to https://docs.akash.network/providers/akash-provider-troubleshooting/close-leases-based-on-image on 19th April 2023.


Below is the suboptimal way of terminating the leases with the selected (unwanted) images (until Akash natively supports that).

Suboptimal because once the deployment gets closed the provider will have to be restarted to recover from the account sequence mismatch error. Providers already do it automatically through the K8s's liveness probe set to the akash-provider deployment.

The other core problem is that the image is unknown until the client transfers the SDL to the provider (tx send-manifest) which can only happen after provider bids, client accepts the bid.

@andy108369
andy108369 / celestia.yaml
Last active March 17, 2023 14:25
Akash deployment manifest (SDL) for Celestia
# HW reqs for light node https://docs.celestia.org/nodes/light-node/#hardware-requirements
# Testnets & RPC endpoints https://docs.celestia.org/nodes/participate
# Images:
# blockspacerace: 0.7.1
# mocha: 0.6.4 (no docker image tag -- https://github.com/celestiaorg/celestia-node/issues/1702) -- `ghcr.io/celestiaorg/celestia-node:sha-747c9e5`
# arabica: 0.7.1
---
version: '2.0'
services:
celestia: