sysdarch is also arch install optimized for latency instead of throughput (from those grounds inhreits the choice of using ext4 instead of btrfs). making sure that full pre-emption is always turned on, threaded irqs are enabled (for the benefit of USB audio interfaces), default user is added to 'realtime' group etc.

It differs from audio/studio distributions in the sense that I use balanced decisions and choices but don't break the whole system for questionable benefits :-)

It runs Bitwig Studio with yabridge or FL Studio with wineasio really well and that's like the stimuli in the first place ;-)

I think I slowly make it more generic and polished over time because it has sort of its own nice as per use case...

My Arch install scripts soon will almost configure Niri and Noctalia (there's only a single bug in the install script that i need to fix).

I maintain the script proactively so that they retain close proximity to my live install because this can be toolized in kernel debugging situations (e.g., reproduce the same environment to a VM).

Maybe I even distro-name this some day. The first name that came to mind was "Idiocracy'. I have no idea where from that spun off ;-)

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/sysdarch.git

@jani ... and if SGX can be mainlined, ANYTHING can be mainlined ;-)

@jani I.e. my logic here is that if code is reduced to something that is exactly all the dog food that I'd happily myself. Not more and not less.

@jani I've heard about this. That makes me think about scope.

I.e. I might make a driver just "webcam" case i.e. subset of oot but make that really polished.

@jani off-topic: This is actually pretty good example on highlighting why LLM is not ideal for kernel dev, despite how one feels about AI in general:

1. In the first phase, if I had used LLM I would have lost the learning experience and my subconsciousness would not processed anything at all.
2. The second highlights why just "any implementation" is not good enough. It must be exactly right flavor of implementaiton ;-) And there are infinite options..

I don't actually know how I would fit AI processing into that without being unsuccesful as per goals.

@jani This is almost always happens to me with feature patch sets:

1. I work on feature like crazy for month or two until things start to "spin".
2. Then I forget the feature for few months.
3. After gathering motivation I redo the feature, and after a few bumps and iterations at LKML things come together :-)

I'm going to take a fresh angle with this. The work early this year thought me how the OOT driver implementation works. I refactored that into some point to be in-tree driver but that somehow did not work.

Now I'm going to create a new branch where I instead take some productized but simple driver such as video-i2c or similar, and then start to mold it using OOT driver only a reference. From earlie work I get it enough to translate its behavior to in-kernel code.

Just had to write this down while fresh in mind ;-)

@jani A new day job happened in March. Also, I wrote a new TPM2 stack for Rust during the Fall. I'm planning to continue with this soon as I'm now fully functional in my day job :-) Thanks for reminding!

@monsieuricon I can live with the burden of this knowledge :-)

I've recently started to use Niri in my main desktop PC. First tiling wm where that some how intuitively works for me, and does not require too much configuration :-)

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/sysdarch.git/commit/?h=main&id=7484242542d5bdd97a507c47959d2117faf6a170

oops, sorry for lying, it is one callback delete moment, anyhow along the lines ;-)

a "one line change moment" ;-)

https://lore.kernel.org/linux-integrity/20251215231438.565522-1-jarkko@kernel.org/T/#u

Somehow these types of patches give more kicks than more complex ones.

Some news outlets etc. seem to translate making translate making support non-experimental into "Rust support getting official". I guess Rust has been "official" past 5-6 years but marked as experimental. I don't understand this type of reporting, or what it meant by "official" to begin with.

Glad previous stuff was merged but new stuff for further streamlining hmac sessions and code around has piled up:

https://lore.kernel.org/linux-integrity/20251214153808.73831-1-jarkko@kernel.org/

Improving hwrng, the prime source of latency issues, has some groundwork laid out, and latency hit should be now stable (as per small variance in expected latency).

After those have been merged it is easy to further to improve hwrng (probably by making it to pool random bytes with fixed size chunk pulls of new data, and serve caller from the pool).

i filtered candidates based on how many times they expressed their dislike of one topic or another in their candidate profiles and used that as heuristics to order the candidates :-) i.e. less dislikes, closer to pole position. i have no idea if it makes the best candidates but i want leadership to have a positive and inclusive view of the future.

casted my vote in linux foundation tab elections :-)

Iterating HMAC encryption steadily to be great again: https://lore.kernel.org/linux-integrity/20251210172027.109938-1-jarkko@kernel.org/

I don't think it has unsolvable issues but it will need some rework. Just needs a few iterations like this.

I think also that once it is functionally and quality wise significantly improved it makes sense to replace CONFIG_TCG_TPM_HMAC with kernel command-line parameters and set of parameters.

Other remarks that I put mostly here for myself as a remainder (I love Mastodon bookmarks):

1. One thing that was properly handled in the first iteration was also that despite ECC-NIST-P256/SHA256 might be de-facto and pratically everywhere in western countries, there's also large population in a distant country at Asia relyingon SM2/SM3. I.e. we eventually need SM2/SM3 to be univeral.
2. Initialization itself should be *conditional* i.e., it will complain if feature cannot be enabled but that's all. It can be then supplemented with "panic_on_warn" style parametr, if somone has a problem with this.
3. Relying only on null key generated at boot is a great for some systems (laptops/desktops) but for embedded systems especially it is a major performance hit. Thus also persistent root key should be an option.
4. During power on hwrng was the worst glitch. The patch set above already improves the situation by making read request "opportunistic" instead of committing to an amount. No grand plan for this but I do have a sack of ideas in my pocket. This will gradually improve over time with no grand plan tbh ;-)

#linux #kernel #tpm

Second Windows post of the day ;-)

What is the pass alternative for Windows that is fully compatible with pass' database?

Microsoft has a multi-decade long history of features, which most people want to proactively disable: https://arstechnica.com/ai/2025/12/microsoft-slashes-ai-sales-growth-targets-as-customers-resist-unproven-agents/

Some things never change ;-)

I have one ThinkPad with Windows and in that when reinstalling the OS, the challenge is always to find out how to mitigate Microsoft's latest attempts to disable local (only) accounts. It's a forever-going puzzle game really.

#microsoft

installed a webcam in order to make a better appearance at telcos ;-)