@duxsco The factorized 16x durability increase should be quite true given how wear-leveling algorithms work on memory technology devices. I.e. they should be expected to end up to the slots in NAND storage which are spread nicely and to least used locations.

I think worst possible question for a job interview I could imagine would be "explain configfs, debugfs, securityfs, procfs, tracefs and sysfs categorizing their roles and differences".

I would not pass.

#linux #kernel

@duxsco My “alternative” approach to the one proposed in the guide (I quite strictly follow it otherwise) has a measurable benefit: it is more durable given the 16 spare copies of the secret material.

I’ve been even thinking to send a patch to kernel-pgp-guide.txt and that was sort of grounds to make this post. I think that just packing ~/.gnupg is somewhat dirty approach…

I’d like to also point out that this approach also mirrors on how paperkey use is instructed, so it is not asymmetrical. IMHO, processes should have only asymmetry if you have some very well rationalized explicit reason to do that when it comes privacy and security.

@duxsco If I really wanted to backup ownertrust I can e.g. make a mastodon post with the contents :-) it does not contain any secret material. We are talking here about backing up material that can neither be lost nor shared.

@duxsco I can pull public keys from keyserver and ownertrust is neither something that cannot be re-created.

Public key restore:

gpg --recv-keys 5107E66D34788A93E3227C903AB05486C7752FE1

not 16 USB sticks, only couple but both have 16 spare copies of the same secret key. and i also have the doomsday printed backup :-)

In Linux kernel maintainer PGP guide I don’t understand the section “Back up your whole GnuPG directory”, and it is also asymmetric with the section discussing paperkey.

AFAIK, this should be sufficient:

gpg --output "priv_0.pgp" --armor --export-secret-key

I do 16 of these and then copy those to an USB stick (i.e. one for each hex digit).

#linux #kernel #pgp

Now that I understand how Ubuntu TPM2 boots looking into OpenSUSE systemd boot version:

- https://news.opensuse.org/2023/12/20/systemd-fde/
- https://www.youtube.com/watch?v=drgo6pvn5hI

I'll check also Fedora albeit I'd guess it is like OpenSUSE (follow cross-distribution standard ways) and unlike Ubuntu (ignoring the common good).

#amigo is a bliss (and also has a linux version) https://www.youtube.com/watch?v=DB6mkL6x1DE #audio #plugins #commodore #amiga

these have been best #headphone's ive had so far both for #music (listening and producing) and #teams etc meetings. and fully repairable and from recyclable plastic: https://aiaiai.audio/headphones/tma-2-studio-wireless-plus

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 tried Arch Linux first for some time when looking at to what switch from Ubuntu (which I used since 2004 to last year) and I think it is really good! I still use it for more complex test VM's (when needing something more like a distribution than BuildRoot). The reason for ending up with OpenSUSE was the binary packaging part that I mentioned.

I.e. how features are engineered feels very "German" in the good sense of the word. Sometimes ugly but always useful and made to last :-)

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.

Comparing now how SDIO boot works with the official SDK. I don’t know where “SDIO” comes from but it should boot all from SD and it is the term used in the quick start guide.

The same guide does not give whole a lot of promised as it just states that:

StarFive recommends that you use 1-bit QSPI Nor Flash mode since there is a low possibility that the VisionFive 2 may fail to boot in eMMC or SDIO3.0 boot mode. Try restarting the VisionFive 2 if fails to boot in eMMC or SDIO3.0 boot mode

Probably something like BeagleV would more convenient but it was not yet even publicly announced when I ordered this. And even if I probably eventually get it having multiple pieces for hardware is nice for comparison.

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