Weitian LI liweitianux

dfvmm Design

1. Design Goal

dfvmm is a DragonFly BSD virtualization stack for efficient container services whose isolation unit is a virtual machine. A container sandbox receives a real hardware-virtualized guest kernel and a deliberately small modern I/O surface. The goal is strong VM isolation with a short, efficient path from an OCI task to guest execution.

Which Mesa versions will talk to an old amdgpu? A survey of the DRM version gate

Mesa's AMD code refuses to initialise below a minimum amdgpu uAPI version, and that minimum has been raised four times. If you maintain an out-of-tree or downstream amdgpu — a BSD port, a vendor fork, a frozen kernel — this decides which Mesa releases you can ship, and the answer is not "whatever is current".

Everything below was extracted mechanically from a full Mesa clone (226783 commits, 944 tags) and from Linux's amdgpu_drv.c version log. The extraction points are documented at the end so the numbers can be re-derived rather than

FAQ on the xz-utils backdoor (CVE-2024-3094)

This is a living document. Everything in this document is made in good faith of being accurate, but like I just said; we don't yet know everything about what's going on.

Update: I've disabled comments as of 2025-01-26 to avoid everyone having notifications for something a year on if someone wants to suggest a correction. Folks are free to email to suggest corrections still, of course.

Background

F-Stack Installation

Author: Weitian LI
Date: 2020-07-16

Environment

OS: CentOS 7.4.1708
Kernel: 3.10.0-957.27.2.el7.x86_64

DragonFly BSD Installation

1. Create Disk Slice

Assume the disk is /dev/da8, to create a slice of about 100 GB.

dfly# cat > fdisk.conf << _EOF_

DragonFly BSD Installation

2018-01-30

Disk Partition

MBR Slice

root# dd if=/dev/zero of=/dev/vbd0 bs=32k count=16
root# fdisk -IB /dev/vbd0

Libuv and libev, two I/O libraries with similar names, recently had the privilege to use both libraries to write something. Now let's talk about my own subjective expression of common and different points.

The topic of high-performance network programming has been discussed. Asynchronous, asynchronous, or asynchronous. Whether it is epoll or kqueue, it is always indispensable to the asynchronous topic.

Libuv is asynchronous, and libev is synchronous multiplexing IO multiplexing.

Libev is a simple encapsulation of system I/O reuse. Basically, it solves the problem of different APIs between epoll and kqueuq. Ensure that programs written using livev's API can run on most *nix platforms. However, the disadvantages of libev are also obvious. Because it basically just encapsulates the Event Library, it is inconvenient to use. For example, accept(3) requires manual setnonblocking after connection. EAGAIN, EWOULDBLOCK, and EINTER need to be detected when reading from a socket. This is a

Fluent-bit rocks

A short survey of log collection options and why you picked the wrong one. 😜

Who am I? Where am I from?

I'm Steve Coffman and I work at Ithaka. We do JStor (academic journals) and other stuff. How big is it?

Number	what it means
101,332,633	unique visitors in 2017

	#!/usr/bin/env perl
	#
	# Cat file to terminal at particular speed of lines per second
	# https://superuser.com/a/526249
	#
	# Usage: cat-lps.pl [lps] [file]...
	#

	use warnings;
	use strict;

	#!/bin/sh
	#
	# Generate version information based on Git tags/commits.
	#
	# License: Public Domain
	#
	# URL: https://gist.github.com/liweitianux/9fce0fc404c41b8f28512e87fbca1562
	#

	dirty_mark='+'