@hunger yep, so for me it is somewhat is easy choice because I’m the main consumer of my own product.

For instance the first pieces of functionality are response code to (spec) mnemonic decoding and object enumeration. I wrote those only because that will free from having to use tpm2_rc_decode and tpm2_getcap for this again.

Consortium projects can have sometimes issues that there is bunch of people who do not actually use it every day in their tool set. I.e. ‘’let’s do something ugly that covers our spec” type of acting ;-)

The second problem is that often in such projects moving changes to upstream can take ages because nobody cares that much. So I can either choose:

1. Have arguments, frustration and anger at Github issues.
2. Write meaningful functionality that I need and use straight out of the bat.

All I did in 48h improved my kernel flow at instant. That is at least measurable benefit. Doing for myself, not for users ;-)

Still my #TUI file manager of choice after all these years.

Closed my tpm-rs bug because I do not want to contribute to that project: https://github.com/tpm-rs/tpm-rs/issues/71#issuecomment-2171360982

Why? I think mine is better or will grow so much better than this. It is more idiomatic #Rust, and generally less layered and more lean and mean ;-)

I will review merge requests for mine tho, on the basis of common sense and code quality tho: https://gitlab.com/jarkkojs/tpm2_library/-/issues

#linux #kernel #tpm2 #rustlang

@cgwalters @fale I'll play with it once have some bandwidth to get better idea what it is and what it isn't ;-)

@cgwalters @fale BTW, is the Fedora version up to date or would it be more advisable at this point to build from upstream (0.1.11)? Or is there a more bleeding edge copr for this work?

I have personal interest for this because to this day I’ve used libvirt for development environments and qemu-system-* for more automated QA [1]. For the former use case this might be my entry to popular “development containers” ;-) So I might be even willing to fix some issues along the way, if I encounter any.

I’m more of a “allow list” than a “deny list” type of person, and thus Linux containers have felt to me quite bad to this day, to be honest.

<personal-and-extremely-subjective-opinion> Docker is a great example of a successful duct tape product to fix something broken to appear as unbroken ;-) Market was formed by bad design decisions in kernel (emphasis on subjectivity of this opinion) [2]. </personal-and-extremely-subjective-opinion>

[1] https://gitlab.com/jarkkojs/linux-tpmdd-test [2] Mainly speaking about the “evil net of namespaces”, which is a mess. I think Cgroups in its second iteration is quite good actually for what it does.

@cgwalters @fale OK, that's really cool progress!

I should have put my words better but does it use like same tricks and ideas still, like e.g. using DAX as a tool to bypass page cache of the guest kernel? Does this have some new ideas in the nitty gritty details level? Obviously heavy use of virtio like anything in this part-container/part-vm space...

put some #feedback about size units to a #fedora #magazine #article ;-)

https://crates.io/crates/tpm2_cli 0.3.0, 634 downloads after 48h of starting of development.

tpm2-cli 0.2.3: https://crates.io/crates/tpm2_cli

#tpm #tpm2 #linux #rust #rustlang

TPM2 command encoding with #bincode and #serde:

            let options = DefaultOptions::new()
                .with_fixint_encoding()
                .with_big_endian();
            buf.extend(&options.serialize(&(Tag::NoSessions as u16)).unwrap());
            buf.extend(&options.serialize(&22_u32).unwrap());
            buf.extend(
                &options
                    .serialize(&(CommandCode::GetCapability as u32))
                    .unwrap(),
            );
            buf.extend(&options.serialize(&(Capability::Handles as u32)).unwrap());
            buf.extend(&options.serialize(&HR_PERSISTENT).unwrap());
            buf.extend(&options.serialize(&1_u32).unwrap());

#rust #rustlang

@Beowulf Thanks, I will retry once I have an urgent need for update. I use relatively small collection of plugins, and trivial configuration so I don't particularly rush ;-) https://gitlab.com/jarkkojs/skeleton/-/blob/main/.config/nvim/init.lua?ref_type=heads

Well, these authors cut right to the chase in this paper!

#LLMs
#AI
#GenerativeAI
#bullshit
#ethics
#truth

Just noticed that #aerc has native support for #zoxide: see :z. #email

@kornel Hmm, well it is not a bad workaround, thanks!

And also would probably help writing bindgen style utilities for Rust (less corner cases when porting from C).

Would make porting all sorts of old protocol stacks to #Rust so much easier if the enum fields could have aliased names. #rustlang

I'm looking into repealing and replacing the error type with this with the error type from my lab project: https://github.com/tpm-rs/tpm-rs/issues/71

#tpm #tpmrs #rust #rustlang

@ljs thanks, found this entertaining...

Language Server Protocol really would need a competitor with a #plugin based architecture.

Then editor and analyzer could have:

1. A better memory and caching strategy.
2. Both faster performance and lower operation latency.

#LSP is IMHO is exactly like the worst ideas of lrzsz modified to work as a language analyzer.

#telescope is awesome with the #kernel tree #neovim