Just some tips I gathered over time. All in one easily reachable place so I can share it wherever I want.
Please note that unless you see a shebang (#!/...)
these code blocks are meant to be copy & pasted.
Some of the steps will not work if you run part of them in a script and copy paste other ones.
On another Debian (x86 or arm64, doesn't matter much).
apt install distrobuilder qemu-system-common
Create a configuration file (debian.yml for example) for your LXC image :
image:
description: |-
Nearly stock Debian Bookworm image
#!/bin/sh | |
# | |
# FOR USE IN OPENWRT | |
# This script creates a guest network fully isolated from the main one. | |
# Tested on a Xiaomi AX3000T router; should work on any OpenWRT-powered router. | |
# | |
# - Ensure the Wi-Fi interfaces retain their default names (radio0 and radio1). | |
# - For enable download/upload limits, you MUST install the sqm-scripts package on your OpenWRT router. | |
# - For enable roaming (aka wifi mesh): |
#!/bin/bash | |
# Setting Up OpenWRT on a Virtual Machine with Proxmox | |
# Based on: https://community.bigbeartechworld.com/t/setting-up-openwrt-on-a-virtual-machine-with-proxmox/257 | |
# Set your wished version: | |
export VER="23.05" | |
export ARCH="amd64" | |
export INDEX_URL="https://images.linuxcontainers.org/images/openwrt/$VER/$ARCH/default" | |
#export BUILDDATE=$(date -d "yesterday" '+%Y%m%d') |
By default Linux distros are unoptimized in terms of I/O latency. So, here are some tips to improve that.
Most apps still don't do multi-threaded I/O access, so it's a thread-per-app which makes per-app speed always bottlenecked by single-core CPU performance (that's not even accounting for stuttering on contention between multiple processes), so even with NVMe capable of 3-6 GB/s of linear read you may get only 1-2 GB/s with ideal settings and 50-150/100-400 MB/s of un/buffered random read (what apps actually use in real life) is the best you can hope for.
All writes are heavily buffered on 3 layers (OS' RAM cache, device's RAM cache, device's SLC-like on-NAND cache), so it's difficult to get real or stable numbers but writes are largelly irrelevant for system's responsiveness, so they may be sacrificed for better random reads.
The performance can be checked by:
- `fio --name=read --readonly --rw={read/randread} --ioengine=libaio --iodepth={jobs_per_each_worker's_command} --bs={4k/2M} --direct={0/1} --num
Here's how to use Home Manager without home-manager
.
@proofconstruction is my witness.
First of all we have to make sure that the version of Home Manager matches the Nixpkgs release we want to use for our user environment configuration. Otherwise we will almost certainly get into trouble with mismatching interfaces.
We start out with a function that takes Nixpkgs as pkgs
and fetch the appropriate Home Manager release.
We get the given Nixpkgs version string from pkgs.lib.version
and split it into the .
format with lib.versions.majorMinor
.
Installing Nautilus directly from Nixpkgs in Non-NixOS systems have no support for mounting sftps and other features that needs gvfs.
The solution for this is to install gnome3.gvfs
in your packages list and then setup the env variable like this:
home.packages = with pkgs; [
gnome3.gvfs
gnome3.nautilus
];
{ localSystem ? builtins.currentSystem | |
, crossSystem ? { config = "x86_64-unknown-linux-musl"; isStatic = true; useLLVM = true; } | |
}: | |
let | |
# Fetch the nixpkgs-cross-overlay sources. | |
src = builtins.fetchTarball "https://github.com/alekseysidorov/nixpkgs-cross-overlay/tarball/main"; | |
# Use the nixpkgs revision provided by the overlay. | |
# This is the best way, as they are the most proven and compatible. | |
nixpkgs = "${src}/utils/nixpkgs.nix"; | |
# Make cross system packages. |