Static traits are really "3rd macro language" of Rust, when observing how they translate into ELF binary.

One perhaps not so obvious observations from Rust that at least I've gathered over time is answer to this question:

- There are traits and dynamic traits.
- Which one to pick by defacto?

Dynamic traits are most of the time the best pick in my opinion, and I base it on:

1. Smaller binary size.
2. Shorter compilation times.

#rust #rustlang

@argv_minus_one I don't about those other crates you mentioned but for this i really just need clap to get the job done.

@argv_minus_one I ended up to approach where all protocol is JSON between the service and cli but inside cli, clap does the translation. Best compromise for my needs and application. That way I can ad-hoc test with nicer syntax and send JSON from programs.

I rewrote the USB factory program that I've been talking about now in Rust based on my C PoC and the patterns for using io_uring while using it.

Reality hit and there's need to also talk to my program for managing things like USB hubs and ports, and images used as sources for them.

I first did JSON protocol yesterday, but it really makes the ad-hoc testing heavy. It's probably great when you have a product shipped and JSON is spoken by computers to each other but for human on terminal interaction it is a nightmare.

Today I found like ultimate solution for client-side of this: Clap. You need exactly one parser for a simple command-language, and then the commands that are typed are subcommands of that parser. And Clap has rich set of features what those contains.

Stuff coming back from program is still JSON (like listing of stuff) but since it is always data (vs not code + data) I will million great ways to fixup that part :-)

Definitely a trick to my hat of tricks that I will re-use also on other languages to get quickly ad-hoc command languages setup!

#rust #rustlang #clap

There's coding conventions, commit message conventions (kernel has one, there's conventional commits etc.) but is there log message recommendations?

I'm mainly thinking in context of system daemons (not web services or internet exposing stuff).

You can e.g., say that something "failed" or alternatively you are "unable" to perform that task etc. I've worked on this small daemon for two weeks and this is the stuff where I don't know what I'm doing.

Actually, I often have hard times reviewing log messages even as a kernel maintainer. I don't really have any guidelines for klog messages that would stick on me. Maybe there should be a document for this like we have for coding conventions and patch submissions. I dunno.

I don't know how smart it is but sometimes when I have access to a machine with no ability to change the shell, I'll add this to the end of .bashrc:

exec fish -l

I've migrated from Zsh to Fish for that same exact reason after 4.0 came out: if you cannot install packages, you can still do cargo install.

Ubiquity is really everything in debugging and hacking for me. Sometimes it goes other way around. E.g., I understand the benefits of neovim but I stick to regular vim it's usually already there (even in macOS). And in my experience it does better in extreme conditions e.g., system-on-FPGA through serial port (probably because of lack of client-server and thus less steps) 8-)

Happy 40th annivesary to #Commodore #Amiga! 🎂

@Aissen @mjg59 And when reaching bigger user volumes Microsoft will need better crossplatform support too, as there's bunch of non-windows commercial uses for linux (and other OS) not being mobile phones, microwave ovens or server racks. E.g., mainframes would need better Intune support as its ecosystem grows. This makes Himmelblau also realistic project in its goals in terms of risk/gain factor. It will likely succeed if it is just implemented properly.

@Aissen @mjg59 And from Linux Client profile the most important takeaway is that obviously it is made purposely a joke. And most likely MS has no plans for legal actions against Himmelblau. They just want to keep decisive power when to stamp it. It's a Samba alike situation ...

@Aissen @mjg59 Yes, and this is the takeaway from my mumbling: Himmelblau is writing a "Windows client" :-)

Looking forward to contribute to this project (they are using tpmrm0 behind the curtains so that way I've already early started :-) ) and encourage others to do so too. This is actually important.

@mjg59 I wonder why there is so little noise about Intune. I started to look for projects that might integrate with it immediately when I first heard about it last Spring. Microsoft is totally owning the game right now as they just do whatever they want without much of any real debate, and with the weight of Azure they end up defining what machine authentication for the industry by large, single handedly.

🎙️PODCAST ALERT: Linaro's #virtualization expert Alex Bennée recently featured on the #OpenSource Way podcast where he talked about the emulator project #QEMU and how it helps the open source #software ecosystem. Check out the podcast here 👉 https://ow.ly/zV7h50Wtc2Z

I heard from Himmelblau developers that they are basing their work heavily on tpmrm0, which made me of course happy, as it is one of my contributions some years ago :-)

When I worked on that feature in the Spring of 2017 I thought that nobody will use it, as it is just way too niche, and I could not fully convice myself that it would bring much useful application on top of /dev/tpm0. And there was already IBMTSS and Intel TSS2.

James Bottomley did a lot for this one
in particular tricky dev management code and extended swapper I had put together also for sessions, in addition to objects.

Definitely gives me the needed boost after holiday season to look more into Himmeblau project and gives some faith that I could be useful somehow over time in that ecosystem :-)

#linux #tpm #himmelblau

@mjg59 right, for what is worth Himmelblau itself is implemented with Rust which is probably a good choice to move forward

@mjg59 Microsoft does have Linux Intune client profile but it is a joke. It's missing all the actually interesting crypto capabilities to put this short. As a consequence the official Intune App for Linux is not a target of interests to anyone.

We do need "Edge" functionality tho to communicate with local services and Siemens has implemented that in https://github.com/siemens/linux-entra-sso (Firefox ok'ish, Chrome early phases). This extension can run both on top of intune-portal (daemon that comes with Intune App) and HImmelblau as it is just protocols that matter in that integration."Edge" (or linux-entra-sso) authenticate essentially to a local broker who then talks to MS, and yeah nothing too suprising here really :-)

Himmelblau addresses the problem of Linux Client profile essentially by pretending to be Windows, so it's both software development and reverse engineering (via analysing packet captures) project. Microsoft does not try to purposely shut it down but neither has wanted to endorse it so far, i.e. they are doing just what they always do. :-)

As software project there's two flavours of daemon: other for OAuth with MS-OAPX extensions doing authentication and other doing kerberos renewal, answering queries coming from the cloud (e.g. machine state related queries)

I've been reading and experimenting about a month or something like that (heard first about the project in May), and done modest PR (fixing systemd unit for debian), I wrote above out of my memory just to check what i can still remember from it after coming back from holidays so keep that in mind but i guess this should give some starting points at least :-)

@mjg59 just out of interest and curiosity: have you gathered any experience with himmelblau yet, i.e. the project reimplementing *windows client profile* by the means reverse engineering the protocol with packet traces?

it's just something that has recently (early summer) evolved into a priority topic in my professional life now and in foreseeable near future, thus the interest.

@avlap2 i guess it is working out for you whatever you do. which is great obviously. i'm not debating because nobody is paying for debating at 11:30 PM :-) this is how i've experienced my past life on this topic overall, and it has nothing to do with some imaginary absolute set of correct answers.

@avlap2 yeah so how i see big picture is that i don't think about the tool too much. using excel is as good as using C or Rust if it solves an actual problem.

and it is always good remind oneself that fancy code has zero effect on user experience. and user experience is really everything. so it's IMHO best to "just do something" never mind the too. that's sort of at least my philosophy overall.

even when developing a driver and low-level daemon, only end users define what is great and what is not that great. e.g. better error recovery, failure tolerance etc. map directly to the reporting capabilities on what can be reasonably represented to the user.

users neither base their choices based on how seasoned the developer (or company) is. over-analysing your "level" in any creative or further artistic work is a disease and it helps to recognize this fact.

in music there's of course like spotify shit tracks but there's also like super skilled music which sounds so fucking horrible that you wish you were dead (yngwie malmsteen for one but not mentioning any names here).

@avlap2 it's too broken for that but on leisure time broken is "interesting" :D C is one of the best things a person can experience during lifetime of all experiences known and yet to be discovered but it's a productivity choice here more than anything else ;-)