Jarkko Sakkinen

Even by the late 90s metrics, disregarding of having per device UUIDs is probably worst mistake in an universal hardware standard that I know at least :-) It's like having 0day in a standard. Or, actually it literally is a 0day in a standard.

#USB #infosec

It does have also "known good" flagging for ports identified by attach (method actually used in the wild as the primary way to uncover topology) but over time i hope this comes less and less useful (and it is always smart to record verified facts if nothing else, to uncover software bugs).

Internal and external builders are separated because they can be really conquered by combining context dependent information e.g., in the case of internal topology outside of USB, it can be sometimes useful to peek also PCI. It is also the part that has variance as par hw platform architecture.

Different hw platforms have their own obscurities so through quirks it upscales to arbitrary amount of work :-) i'll eventually publish this work as "usb-topology" crate. it has builders for iimmutable (and mergeable) graphs of hubs and pluggable ports. 2/2

i've spent two weeks on USB, only to answer the question of "how many pluggable USB ports". i'm now at one false positive on HP Elitebook G8 for internal controllers, and can probably scale this to the range of recent generations of that product line. 1/2 #usb #rust #rustlang

I think I should refine this a bit some day. main plan is to uplift it enough to have companion rz/sz equivalents with nicer interface and cancel (yes, zmodem does support cancel) :-) it's working code but not up to "quality standards" yet...

docs.rs/zmodem2/late...

#rust #rustlang #zmodem

i made a little #cargo registry browser into a single #fish function 😀

Home | D2 Documentation D2 is a modern DSL that turns text to diagrams.

I ever really got into habbit of using #Mermaid as its "interpreter as a service" is an idea that sounds like someone from DailyWTF had made it :-)

#D2 has a compiler (implemented with Go and not as a self-hosted web service), so need check it out some day.

I wrote in detail one possible breakdown of tasks required for making mailweb useful for TUI file managers (mc, ranger, joshuto):

codeberg.org/jarkko/mailw...

I need it for mutt only but I'm obviously open for PRs ;-)

#mutt #mc #ranger #joshuto

For mutt/aerc/alpine etc. text/plain is irrelevant for the use case but adding that would make this generic email opener for midnight command, ranger and similar tty based fm's. I.e. you could hit a file in the fm and browser opens it with all images displayed correctly.

It converts HTML body and its resources to a static web site (despite archaic) by the means of extracting its parts and subsituting CID references with file URLs. Thus, I thought since it converts mail to web sites, mailweb is a great choice ;-)

i retracted from "multidepart" for my mail extractor tool as apparently there is a random EU fund with that name and thus it lost its appeal :D

i bumped the minor, renamed the project and published a new crates.io project: crates.io/crates/mailweb

#mutt #aerc #mailweb

[For the record, as JSON format escapes new line, carriage return and other control characters, a "normalized" JSON string has total zero newline characters. i.e. that graph layout for JSON usally emitted is for humans at the cost of adding complexity to post-processing]

My favorite long-running example of counter-productive usabilityin the command-line (even before Rust appeared) is laying out JSON output in any possible way, while being machine-readable any JSON processor (like jq) would do it through pipe. Even tools like iproute2 do this for no good reason.

adding features can also make a tool worse. it affects in the end the user experience a lot. even a great feature adds more vocabulary and grammar. and cargo makes too easy to pile crates that using them for some is exactly like smoking crack.

It hit me when I did couple of command-line tools last week (lsiommu and multidepart) why i don't know many command-line tools made with rust that i don't proactively hate: it's the overconsumption of the features and not that ubiquitos output across the machines :-) #rust #rustlang #tty

does not makes sense to depend on cjson or similar, as there is no parsing (i.e. not a sink) and neither there is formatting: github.com/puavo-org/ls...

this looks almost ready in terms of deps etc. for tagging a release and submitting to #debian packaging pipeline :-) my custom JSON renderer purposely emits just "one big string", as it is best for machines, storage and further consumption (e.g., to jq for formatting) #linux #iommu

added aerc bindings (shown in the crates.io page) but unfortunately have only mutt setup meaning that they are untested by me:

crates.io/crates/multi...

#mutt #aerc #email

GPL protects the IP from unfair use by competitors. A copyright a copyright owner obviously retains also the relicensing capability.

Starting with MIT/Apache is a one-way street and is like the worst licensing choice as at the begin because it makes no sense tie hands like that as the first act.

For any commercial entity starting with GPL or AGPL when open sourcing is from corporate governance perspective usually the best choice to start with, unlike MIT or Apache, which are like the most usual choices.

#opensource #licensing #copyright

Unlike in the original viewhtmlmail, multidepart does not freeze the terminal window up to a timeout to hold on for browser as extracted emails are not deleted at exit. Instead, it maintains a N slot LRU cache of extracted emails, which as a side-effect addresses the risk for a race condition :-)

crates.io: Rust Package Registry

crates.io/crates/multi...

This is along the lines clone of viewhtmlmail (popular among #mutt users).

codeberg.org/jarkko/multi...

It's pretty much done for crates.io at least :-)

#email

designing kicks is one of worst pitfalls in sound design in the sense how much you can waste time on it when you could have just picked a sample :-) especially with todays precission tools. that said, loved the video!

for trivial command interpreters in rust you can just re-use clap to parse the line input and define the command language as a single clap parser instance :-) it obviously does not care about the fact that it was not typed from terminal. #rust #rustlang #clap

2014: mumble rap
2025: mumble trump

western culture is slowly draining into recursive meme singularity :-)

I see Twitter’s drive to get high quality advertisers is panning out

I.e. some might do Internet exposing services, which is pretty far for any stuff I'm working on.