Jarkko Sakkinen
Posts
4549Following
317Followers
476OpenPGP: 3AB05486C7752FE1
@gregkh I think softer recommendations/practices would go a long way. I would not want to use machine readable tokenized system for log messages. For that something like eBPF is probably a better idea :-) And using klog "as instrumentation protocol" (or that kind of picture I got from your description) is scary idea from security standing point.
1
0
0
This is like continuation to https://github.com/puavo-org/lsiommu i.e., mainly goal is to rip off random scripts :-)
1
0
0
Jarkko Sakkinen
jarkko
This is along the lines clone of viewhtmlmail (popular among #mutt users).
https://codeberg.org/jarkko/multidepart
It's pretty much done for crates.io at least :-)
#email
https://codeberg.org/jarkko/multidepart
It's pretty much done for crates.io at least :-)
1
1
0
Even in kernel log messages are total chaos. It would be also bad if they were forced to be some weird tokenized structure (aka machine readable) and they loose their purpose, and you can store that type of history data elsewhere tuned for the application.
The middle-ground would be to define recommendations choice of words, vocabulary and grammar to apply in broadly defined scenarios. This would especially help in projects such as kernel where non-native speaker might have difficulties to figure out the "right language" by instinct.
Thus, it would relax the project ecosystem more than it would make it more constrained, as you don't have to spend too much energy in such a low priority topic, and focus on important matters.
The middle-ground would be to define recommendations choice of words, vocabulary and grammar to apply in broadly defined scenarios. This would especially help in projects such as kernel where non-native speaker might have difficulties to figure out the "right language" by instinct.
Thus, it would relax the project ecosystem more than it would make it more constrained, as you don't have to spend too much energy in such a low priority topic, and focus on important matters.
1
0
0
Jarkko Sakkinen
jarkko
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
- 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
1
1
3
@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.
0
0
1
Jarkko Sakkinen
jarkko
@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.
1
0
1
Jarkko Sakkinen
jarkko
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
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
1
1
0
Jarkko Sakkinen
jarkko
Edited 20 days ago
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'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.
1
1
2
Jarkko Sakkinen
jarkko
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-)
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-)
1
0
2
@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.
0
0
0
1
0
0
Jarkko Sakkinen
jarkko
@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.
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.
1
0
0
@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.
1
0
0