two copies of me, i like to use different color smiley for each, and name them in web services as "yellow key" etc. :-) #yubikey #openpgp #fido2

When I backup #OpenPGP private master key to USB stick I tend to do priv_0.gpg, priv_1.gpg up to priv_f.gpg. They are identical but little bit of redundancy should bit more durability. I.e. hex amount of spare copies.

execmem patches v7 providing initial pieces of framework for allocating trampoline executable memory for tracing tools, and kprobes implementation for RISC-V: https://lore.kernel.org/linux-riscv/20240326134616.7691-1-jarkko@kernel.org/T/#t

#tracing #kprobes #linux #kernel

I've been pretty satisfied with #OpenSUSE since I started to use it somewhere in the latter part of last year :-) Some UI workflows are not as off-the-shelf polished as in #Ubuntu but payback comes from mostly relying in the common sense standard compliant solutions and not trying to hack features "not yet possible". And when comparing to other rolling release distributions I find it nice that you get the latest shit but mostly as binary packages so update times are always fast.

Six months before my contract at the university ends so better start looking for vacancy preferably a safe corporate job. Not too many requirements expect needs to support being a kernel maintainer...

Hmm.. With DIP switches set to “SDIO” mode, VisionFive2 SBC gives the most informative error message ever:

BOOT fail,Error is 0xffffffff

I’d guess the last value is -1 in 1’s complement format but other than that 🤷

I used #BuildRoot and visionfive2_defconfig. Not sure how feature complete so maybe I will try the official SDK for comparison.

execmem allocator for #tracing and RISC-V support for applying it for #kprobes v6:

https://lore.kernel.org/linux-riscv/20240326012102.27438-1-jarkko@kernel.org/T/#t

#riscv #linux #kernel

Kprobes w/o modules for RISC-V v5

https://lore.kernel.org/linux-riscv/D036FYBQUMIX.L5TL0SUCAO49@kernel.org/T/#t

s/textmem/execmem/ (a typo)

#linux #kernel #kprobes #riscv

Does anyone provide static and pre-compiled #busybox binaries for #riscv? For #x86 busybox.org provides this but other than that I have no idea.

I guess the software version of Moore's law is that software gets exponentially worse as hardware gets exponentially better. For instance, word processors do mostly the same tasks as in 1993 but do not run with 386 and 4 megabytes of RAM :-)

#amiga #sampler https://www.potenzadsp.com/amigo/

#audio

Not my expertise area at all but I was just thinking how would you measure relative round-trip time of syscalls on let's say between x86 and RISC-V. i.e. when you have your measurements how would you normalize the results for meaningful comparison.

After about two'ish years of use I've reached the point with #aerc #email client that I do not pro-actively hate it :-)

The withdrawal symptons of #mutt are over...

#Rust installation instructions go like:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

But what you actually want to do most of the time, is probably:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | bash -s -- --no-modify-path

#rustlang

making my first arch/riscv patch ever :-) nothing flashy but you have to start from something in everything… #linux #kernel #riscv

Learned a bit o #python #gnupg bindings to automate tasks, as gpg command line can be sometimes a bit confusing and ambiguous.

E.g. this is how to purge revoked keys after gpg --refresh-keys:

#!/usr/bin/env python3

import gnupg

if __name__ == "__main__":
    gpg = gnupg.GPG()
    keys = gpg.list_keys(True)
    for k in keys:
        info_db = k['subkey_info']
        for subk in k['subkeys']:
            info = info_db[subk[0]]
            if info['trust'] == 'r':
                fp = subk[2]
                print(f"{fp} {gpg.delete_keys(fp, expect_passphrase=False, exclamation_mode=True)}")

Definitely worth of trouble because I’m super-talented on making destructive mistakes with command-line arguments :-)

have to admit that i’ve missed this before but better late than never: https://libguestfs.org/. super useful #qemu

In addition to looking how #Ubuntu #TPM2 boots I'm also somewhat interested on how e.g. #Fedora and #OpenSUSE are approaching this, or will do so in future. I have OpenSUSE in my main desktop but it is still using traditional passphrase style...

IMHO best way to address AI plagiarism would be to educate the staff on the topic.

E.g. just with human eye and simple comparison you can often spot snippets of wikipedia articles.

Also, models always lag behind so by adding as up to date stuff as possible to assignments the applicability of AI will decrease by factors.

Generally speaking AI risks should be dealt same way as vulnerabilities and malware, i.e. you should think it as a process rather than a something ending up with some final solution.

Just looking at what #Ubuntu installation stores #NVRAM of #TPM chip when installed with #TPM2 sealed #encrypted boot:

$ sudo tpm2_getcap handles-persistent
- 0x81000001
- 0x81010001

So: I guess the 2nd key, which has a policy bind, is what is “the fast path” with #PCR unsealing, and the first key is “the slow path” unsealed with the value given by snap recovery --show-keys.

Is this how it is laid out?