Trying to deploy #systemd to BuildRoot build:
Filesystem found in kernel header but not in filesystems-gperf.gperf: BCACHEFS_SUPER_MAGIC
Filesystem found in kernel header but not in filesystems-gperf.gperf: PID_FS_MAGIC
I think I might know how to fix these tho so should not be an issue.
I had QEMU style build. I’m repeal and replacing that with a build that builds 2GB disk image ESP/UEFI compatible. That can then supplied to qemu/libvirt or burned to stick and booted with hardware.
I wonder what is the policy of putting something to scripts/
(not to vmlinux
) that is written with #Rust? I.e. build time utility. Just curious.
And actually, since bindgen
is installed from crates.io, not from kernel tree, should it be actually submitted there, and not to the kernel tree?
Kernel documentation gives pretty bad rationale for bindgen
being in Cargo: “The bindings to the C side of the kernel are generated at build time using the bindgen tool. A particular version is required.” I’m sure there are good reasons to install it using cargo
but why the documentation does not list those reasons, no matter how obvious they might be to some.
So I guess I put my build time tool to crates.io because at least first it is an experiment, and secondly bindgen
is managed like this. But even this does not conclude the story fully. I have no idea in what license that out-of-tree pulled build-time utility is expected to be. It is not documented, or at least I cannot find it documented anywhere.
Other thing that puzzles in #Ethereum and #Swarm is that why waste bandwidth and CPU cycles to #JSON when you could #ASN1 the transaction like:
Root ::= SEQUENCE {
from INTEGER
to INTEGER
value INTEGER
gas INTEGER
gasPrice INTEGER
nonce INTEGER
data OCTET STRING
chainId INTEGER
}
Pretty trivial scalability optimization IMHO. Maybe I submit another talk just to say that hey use ASN1.
NIST said it has awarded a new contract to an outside vendor that will help the federal government process software and hardware bugs added to the National Vulnerability Database (NVD).
NIST wouldnt say which vendor was hired
https://therecord.media/nist-nvd-backlog-clear-end-fiscal-2024
A plea for more thoughtful comments https://lwn.net/Articles/975597/ #LWN
Here are the slides for a talk I just gave about using perf c2c to find cache line contention in postgres:
https://anarazel.de/talks/2024-05-29-pgconf-dev-c2c/postgres-perf-c2c.pdf
I think there would be still space for systems programming language with a constraint from day zero that it would 1:1 compatible with plain C”s binary layout and memory model:
.text
, .bss
, .rodata
and ,data
.All the memory safety etc. fancy features would be then designed within exactly those constraints.
#Rust is essentially a derivative of C++ when compiled to binary, which does not really make it a strong competitor for plain #C. It can substitute C in many cases for sure, just like C++ did, but there’s always need for minimal systems programming language, which also looks elegant in binary, not just in source code.
A compiled C program can be quite easily understood with a binary with no debug symbols at all if you understand the CPU architecture well enough. That is, and will be a strong asset for C.
My game plan for the next weekends Ethprague is this:
tpm2_key_rsa
, tpm2_key_ecdsa
) as a way to give a guarded identity for the machine (or node). TPM_ECC_P256_K1
in TCG Algorithm Repository means that TPM’s cannot natively store Ethereum private keys. Could and should change tho.Feels like 25-30 mins to me. Most importantly, not much knowledge required of #Ethereum, which is pretty alien topic to me :-) About to head soon to the #Tampere airport.
I’m not really even a fan of blockchains or cryptocurrency but I still think that it is good to provide safe and usable mechanisms for any legit task that user wants to use Linux for. So thus I want to enable those and free of charge, in order to keep my position regarding this topic (no affiliations). I only benefit flights to Prague from this work (pay for Airbnb myself).