I think, just based on experience on previous tech revolutions, that #AI is neither useless nor it is going to repeal and replace human labor.

It just hasn’t hit the its roof, or more precisely constraints, yet.

Media only giving voice to either AI companies or AI researchers turned into doomsday predictors, is at least quite strong signal of a bubble.

If you feel that AI is evil, here’s couple of suggestions what you can do:

1. Engage and support open source ecosystem. It is essentially a crowd-sourced alternative to AI where people work together to realize the best possible software for other people and for themselves.
2. Consider #GPLv3 and #AGPLv3 as an alternative to making “standard Github choice” of #Apache or #MIT. It is a self-governing and collaboration enabling licensing model. I think AI makes #GPL more relevant than it ever has been so far in its history. I’ve at least started to pro-actively rethink how I license my own projects, instead of lazily just putting MIT or similar license.

I think that I do as a next #BPF exercise a "poor man's" flame graph generator for #TPM driver, meaning no interaction and make most of VT output ;-)

I could also consider to do it for #kernel #keyring later on but TPM driver is easier to scope: only look at events that end up to tpm_transmit().

Instead of "perf sampling approach" I'm planning to use BPF ring buffer and use that to all backtraces to tpm_transmit() to the user space host program. Then the host program implemented with C will post-process that queue in parallel.

Frequency of TPM commands is low enough so that 1:1 granularity should be possible.

Can't wait to get this done, will be a fun tool for future patch reviews I make ;-)

#eBPF

Here’s a minimal shenanigans for #eBPF #C host, with bpftool taking care of header generation.

Payload (payload.c):

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
SEC("tracepoint/syscalls/sys_enter_execve")
int tracepoint__syscalls__sys_enter_execve(struct trace_event_raw_sys_enter *ctx)
{
	bpf_printk("execve");
	return 0;
}
char LICENSE[] SEC("license") = "GPL";

Host (main.c):

#include <bpf/bpf.h>
#include <bpf/libbpf.h>
#include <signal.h>
#include "payload.h"

static volatile bool interrupted = false;
struct payload *obj;

void do_sigint(int value)
{
	interrupted = true;
}

int main(void)
{
	struct sigaction sa;
	ssize_t ret;

	obj = payload__open();
	if (!obj)
		exit(1);

	ret  = payload__load(obj);
	if (ret)
		goto err;

	ret = payload__attach(obj);
	if (ret)
		goto err;

	sa.sa_handler = do_sigint;
	sigaction(SIGINT, &sa, NULL);
	while (!interrupted);
	fprintf(stderr, "\ndone\n");
	payload__destroy(obj);	
	exit(0);

err:
	payload__destroy(obj);	
	exit(1);
}

Build (build.sh):

#!/usr/bin/env sh

# vmlinux
bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

# payload
clang -g -O2 -target bpf -I . -c payload.c -o payload.o
bpftool gen skeleton payload.o > payload.h

# main
clang -g -O2 -Wall -I . -c main.c -o main.o

# hello-ebpf
clang -Wall -O2 -g main.o -lbpf -lelf -lz -o hello-ebpf

While running trace_pipe is expected to have output like this:

             cat-61135   [011] ....1  8303.116335: bpf_trace_printk: execve
             zsh-61136   [002] ....1  8303.116691: bpf_trace_printk: execve
             zsh-61139   [004] ....1  8303.118436: bpf_trace_printk: execve

#linux #kernel #tracing

Submitted some ideas to rust-vmm/vm-memory how it should be extended to work for confidential (#SGX, #SNP and #TDX) payloads to make it scale for the needs of #Enarx:

https://github.com/rust-vmm/vm-memory/issues/291

#linux #kvm #rust #rustlang

I’ve been wondering over the years when being at #Airport check-ins how come these #PowerShell scripts can possibly ever work.

I know this because I’ve seen numerous times over the years crashed check-in machines. Latest one was late Spring when I visited #Ethprague at #Prague Airport.

I miss the “OS/2” and “Guru Meditation” times of my late 90s and early 00’s in vending machines etc. ;-)

Your local airport is actually airport.bat!

#CrowdStrike

Wrote a pretty good Windows emulator in {fmt}:

#include <fmt/color.h>

int main() {
fmt::print(bg(fmt::color::blue),
"{:1600}", "Your PC ran into a problem and needs to restart.");
}

#crowdstrike

Things that Mastodon spam accounts following me have put in their profiles today:

• "Passionate crypto trader, let's vibe"
• "Full Stack Digital Marketer Consultant"

What a world.

`mmap` struggles with #Rust: https://github.com/enarx/enarx/issues/2580

#enarx #rustlang

https://www.digitaltrends.com/computing/southwest-cloudstrike-windows-3-1/

https://imgs.xkcd.com/comics/crowdstrike.png

In #CrowdStrike outage biggest surprise is not the bug but instead how unprepared they were for rollback.

Lessons learned IMHO from the whole thing is that companies running these platforms should have a test suite, and exercised rollback process for faulty patches.

I.e. I'd focus to the only thing that can be fixed permanently, i.e. the rollback process at scale. Faulty patches come and go.

#infosec

@pinkforest Well I used mutt 1999-22, and email workflow is the most critical thing in my life almost ;-) But I can still try it out and comment if I have anything to say.

What made me try out aerc in the first place was this blog post: http://www.kroah.com/log/blog/2019/08/14/patch-workflow-with-mutt-2019/, i.e. if aerc made any sense to Greg K-H, it might make sense to me, as Greg is a long-time mutt user :-)

IMHO, one place where there is a lot of room for improvement, and I don’t really have a fixed choice per se, is command-line / TUI address book with vCard support, which would integrate smoothly with these popular clients:

1. Aerc
2. Alpine
3. Mutt

ATM, I’m using https://github.com/lucc/khard but I do not love it particularly.

#Microsoft #Crowdstrike #egg 🤣

https://bsky.app/profile/liaofthebay.bsky.social/post/3kxmu7gmxxc2h

#Playtime 2 aka #Ableton session alike extension for #REAPER: https://www.helgoboss.org/projects/playtime

Nice trick in Aerc that I just learned to share IMAP account for personal and kernel.org account:

~ main
❯ cat .config/aerc/folder-maps/kernel.map 
personal = INBOX
INBOX = kernel

~ main
❯ grep folder\-map .config/aerc/accounts.conf
folder-map		= ~/.config/aerc/folder-maps/kernel.map

Should be self-explanatory ;-)

#linux #kernel #aerc #imap #email

One of the most important things to understand in Vim are @: and @@. After learning them, there is rarely need mapping ex-mode stuff to keyboard shortcuts.

Already plain vim has two languages: the operator language and vimscript. By learning all the cool tricks of the former, it is often case that there is no need to do anything with the latter. Often plugins are installed because of lack of knowledge in the operator-language ;-)

#vim #neovim

On #macOS least tedious way to run ALSO full #VM's IHMO (I don't care about #Docker): https://orbstack.dev/

#Apple sucks deeply providing #developer experience but this seems make things somewhat usable. Invention in #orbStack is that VM's use bind mounts (i.e. a bit like #WSL2).

In addition it has great preset gallery, got my Fedora up and running within 3 minutes.

Silva: How to use the new counted_by attribute in C (and Linux)

https://lwn.net/Articles/982275/ #LWN

#rustc blows up completely when replacing a source file under ~/.cargo/registry/src with random data. It really should do better. This is not appropriate way to signal memory corruption, shouldn’t memory safety take care of this? :-) #rust #rustlang

This is how I integrate rusty tags in my .zprofile:

# rusty-tags
[ `command -v rustc` ] && RUST_SRC_PATH=$(rustc --print sysroot)/lib/rustlib/src/rust/library/
[ -d $RUST_SRC_PATH ] && export RUST_SRC_PATH

I still prefer #ctags over LSP.

#rust #rustlang