well, returned back safe #neovim. i did like experimenting with #helix tho and am going change my neovim configuration based on that. I’ve used vim for 25 years so pretty hard to get out of old habbits.

Some glitches that would need to be fixed before I would try it again:

1. Doing quick changes to tabbing was too much effort compared to something like set ts=2 sw=2 et. Creating a .helix directory for upstream projects in not always even an option.
2. I don’t like multiselect, totally useless and confusing feature to me, and the whole philosophy is based on this concept. I generally do not want the text editor to be too symbol aware to the point that it gets in the way. This is actually why I never got into Emacs. It is way too smart editor for me :-)
3. I was not able to format (gq) email paragraphs when responding with aerc.
4. No remote editing so not very nice to use with tmux. I usually open my files from command-line, not from the editor.
5. Probably just user incompetence but I did not know how to exist from that stupid multi-select once I had done search replace. So I exited the whole editor after every single search-replace.

In producing code it is not very important how fast you can write the code because 95% of time goes to QA anyway and making first functional version to actually work with real workloads. So personally I think that new editors optimize a local maximum that does not help to deliver all that much as you might first think.

I'm implementing crate for reading (and later on writing) #polyend #tracker projects :-) Not proactively developed until I get my serial tool in shape tho. After I have that I might write a playback engine for the projects and a command-line player. For reverse engineering reverb and delay algorithms I'm going to use Bitwig Grid and then just compare sampled output until I get it right.

The utility would be e.g. to convert Polyend project to #Bitwig or #Ableton project and stuff like that but to do proper conversion you first need to have a playback engine for comparative testing even though those tools do no need to play anything.

Theoretically I wonder how feasible it would be to generate some HDL and software from same Rust code base. Borrow checker and lifetime parameters give already a framework for that purpose so I guess it could be theoretically possible. #rustlang #vhdl #verilog

Cool apparently got first PR to zmodem2 crate. Now I have an open source community, quality replace quantity I hope :-)

To make manageable #Rust stacks over time, I’ve ended up to following conclusions on how to make I/O connectors between library crates:

1. Internal Read, Seek and Write traits that specify an API that is a more constrained versions of std::io counterparts. Here the masking is used for benefit so that all in-crate code depends on exactly to internal traits.
2. A submodule named std.rs containing std::io implementations and macro shenanigans to use it [1]. This way std can be compiled out if required (e.g. when used with embedded_io).
3. Optionally outside I/O can be embedded with a tuple or enum value containing a tuple.

This way my own crates are pretty easy to glue to std, embedded_io and other crates providing the I/O backend so this sort of indirection makes a lot of sense. The goal is to have a structure with clean separation of internals and connectors to the outside world (which can or might not include std).

[1]

#![cfg_attr(not(feature = "std"), no_std)]
#[cfg(feature = "std")] 
mod std;

#rustlang

In Rust programs one common theme, which is not great for optimizing memory footprint, is the heavy use of collect(). Iterators are a great abstraction exactly for the reason that you can view items as a set without having to brute force deploy them as such in memory. One area where no language paradigm can protect against is the overuse of computing resource.

One good recipe against this e.g. in a commercial setting would be to set a constraint for core components to be no_std compatible and have total artistic freedom in user interfacing parts or e.g. storage backend interfacing part i.e. only in I/O code.

Then early steps are slower but sort of investments instead of debt when memory is considered early on…

There’s little gain with the added complexity of Rust to something like Go if this consideration is not done. Sometimes something like Go could do even a better job because then at least garbage collector considers memory constraints..

#rustlang

Preparing for v0.1 of my #zmodem2 crate: https://github.com/jarkkojs/zmodem2/issues/9. It is heapless and has a context structure that takes less than 2 KB of memory. Not sync but sequential because I want for first version to have just correct implementation of the protocol. Works also in no_std environment.

#rustlang

Great my little zmodem2 crate is now supporting no_std. Not that useful yet before I have made file transfer API sequential (repeated calls, one per subpacket), or even fully async compatible (or postpone async to 0.2).

https://github.com/jarkkojs/zmodem2/commit/bc83180cacf04b5611c4068062408ef0ed75f797

sometimes the most #fortran solution is the best :-) not pretty, probably not too “rustacean” but gets the job done…

https://github.com/jarkkojs/zmodem2/commit/a4ad4508a99b66f46ab9daf0f08956c532285107

now it is pretty easy also add quirks later on without having to maintain a grazy ruleset.

#rustlang

Typography: it matters!

#KerningToo #humor #humour #typography #graphicdesign #writing #writingcommunity

November 2023 - My Linux Kernel work

"-Wstringop-overflow

Late in October I sent a patch to globally enable the -Wstringop-overflow compiler option, which finally landed in linux-next on November 28th. It’s expected to be merged into mainline during the next merge window, likely in the last couple of weeks of December, but “We’ll see”. I plan to send a pull request for this to Linus when the time is right. 🙂 [...]"

You can read the whole post here:
https://embeddedor.com/blog/2023/12/05/november-2023-linux-kernel-work/

core::array::from_fn is a life-saver #rustlang

My #kernel (smoke) #testing ground: https://github.com/jarkkojs/buildroot-tpmdd

I think it is useful enough also update to MAINTAINERS. I’ve also tweaked #qemu scripts to automatically put #swtpm on background and some options what sort of TPM ought to be emulated.

#buildroot #linux

Learned how async works in Rust and it looks like straight-forward to convert #zmodem2 crate to that as I have state machine alike structure for both send and return. Given how slow these transfers I make it async only, not async opt-in feature.

After that only some minor things need to be added and fixed and I can finally start gluing it to https://github.com/jarkkojs/tior and start working on its UI again.

For tior I’ll switch also switch to serial2 crate, which provides simpler API, a pro-active maintainer and fully working Windows serial support, which is not the case with seriaport.

With the asynchronous ZMODEM crate (right now the standard is invoking external program) it is possible to implement file transfer dialog, which shows progress, cancels the transfer according to the specification and generally not get a feeling that system is somehow halted :-)

James Bottomley posted new version of the #HMAC encryption patches for #TPM2: https://lore.kernel.org/linux-integrity/20231127190854.13310-1-James.Bottomley@HansenPartnership.com/T/#t

I spent some time refactoring the tpm_buf changes because they were the major glitch for me in the earlier versions, and those patches have been included now to this series, which is of course great. The series is probably rather sooner than later ready for inclusion to the mainline.

This adds up to the TPM2 sealed hard drive encryption by mitigating bus interposers by a factor. An interposer is an actor intercepting traffic between the CPU and a discrete TPM chip (i.e. not firmware TPM).

A bus interposer can reset a TPM and replay PCR’s as the chip returns to its initial state, which resets them. To mitigate this, kernel creates HMAC session for each TPM transaction and derives session key from the so.called null hierarchy, which essentially provides a new random seed per TPM reset.

Therefore, interposer’s ability to reset TPM decreases because kernel will not be able to communicate with the TPM and that way indirectly a malicious act can be detected by far better chances than ever before.

IMHO, this fits quite nicely to the stuff that #OpenSUSE and #Ubuntu have been working on lately.

I use now #TPM2 sealed LVM/LUKS2 encrypted partitioning in my Linux desktop. No need to type password anymore when booting up great. #Linux #TPM

I switched to #helix editor because three advantages weight me more than disadvantage of having to learn away for #vim shortcuts:

1. Too much legacy.
2. Too many plugins.
3. It is a varying challenge to install the latest version #neovim, which anyway needs to be done in order not to break init.lua (and that big pile of plugins).

So for the price of few weeks inconvenience I can stop spending time on text editor configuration and/or figuring out on how to install it.

I used #vim and later on neovim fo the period 1998-2023, even before using Linux. I switched to vim in MS-DOS from text editor called #QEDIT :-)

Does Rust #Linux already have bindings for network drivers? I’m thinking of making #lowRISC Ethernet driver because the one provided by OpenHW Group is a corpse. It is like made for v5.7 and since not updated. This is the one that is used in #CVA6.

#rustlang

I think I fixup lookup tables for escaping #zmodem traffic by intercepting traffic from lrzsz with “defacto” parameters, i.e. send large chunk of uniform distributed random data. That way I can be sure that I have all the cases, including those not in the specification form 1988.

Later on I can use that as a CI test for my crate. Sort of fuzzing approach. I just need to record all bytes that follow ASCII 24 and that builds my table.

nice that #github allows to turn off issues, if only "pull requests" could also fully disabled #microsoft