Notices by equi DENOG17 ⬅️💨 IETF124 (equinox@chaos.social)

@azonenberg @whitequark I thought the specs file is all you need for that (and it has worked for me so far, though I only do embedded stuff for fun once in a while)

It seemed mostly an issue of picking the correct linker scripts and crt*.o files where necessary, and those are in the .specs…

"How many GCC versions do you have installed?" — "Yes."

@whitequark does it sprout wings and a jet engine if you put it in airplane mode? 😂

@azonenberg @ariadne @astraleureka @lina it could be WAY worse:

when I got my fiber connection, I found for some reason it worked on OpenWRT but not my Debian box. After some digging, it turned out all DHCPv6 packets were 1514 byte Ethernet frames, regardless of IPv6/UDP content len.

Those extra bytes were a bug on the last-hop Cisco switches' DHCPv6 relay/inspection. Random snippets out of the switch's memory.

Including configs.

With other customer's *names and line IDs* (port descriptions)

@whitequark @azonenberg same here, with a twist: if anything the argument for us to move away from github would be that some github features just suck, e.g.:

- poor handling of backports
- poor trackability of PRs across edits/updates/rebases/… (gerrit style)
- repeated annoyances with external CI integration

But sum total the annoyances are below the social cost bar of justifying a move somewhere else.

@whitequark right. Ugh. I've used JS level perf tools before, but no clue about somehow getting useful perf (or trace) out of wasm…

Anyway I shall stop wasting your time, happy hacking & appreciate a whole bunch of your stuff! 😊

@whitequark ah. Huh. I would've expected *that* interface to not be all that different from what libusb does. Never looked at it, Firefox user 😅

@whitequark +9000 on "hard to debug this stuff", I've got a bunch of painful memories debugging around the URB layer & particularly when exactly what happens and why 😬

@whitequark for the USB bits specifically? I would've hoped USB were the bottleneck there, is it just increased request-response-repeat time/latency?

@r @whitequark @artemist longjmpQQ(), just selects a different multiple worlds quantum reality where the longjmp() already happened from the beginning.

@r @whitequark @artemist longjmpVE() that uses reverse van Eck phreaking to transfer program state to another nearby (potentially airgapped) computer and resumes execution there.

@whitequark I have seen "MIIM" maybe once or twice in my lifetime. Most I've seen, people just call it "c45_read" / "c22_read" and the like.

E.g. this bonanza: https://patchwork.kernel.org/project/netdevbpf/patch/20210331141755.126178-3-danilokrummrich@dk-develop.de/

Everything is MDIO.

@whitequark is there a { missing on the 3rd line or am I blind?

Termination? Pffffffffffffffffff

Fibre actually grows on trees here. Wonder what the harvest period is.

Tech ★ Culture

@marcan I'm sorry but you're escalating based on your subjective reading of Christoph Hellwig's mail. He has the opinion that Rust is detrimental to maintainability of the project and is acting to be heard. That's "everything he can do to stop this". He is entitled to (only) that.

This is the opposite of sabotage, which would be covertly attempting to hinder or damage R4L while feigning ignorance.

The way to proceed is for consensus or (Linus') fiat to acknowledge and overrule his concerns.

@marcan denouncing Christoph as a saboteur is not helpful, neither is pulling CoC considerations into this discussion. Acknowledge his opinion and plainly ask for it to be overruled once and for all.

Anything else, like calling him a saboteur needs to come with proof of sabotage. And for calling a CoC violation you better point out exactly how and where he's violating the CoC.

You have different styles of communication. That's what this is AFAICS, no more, and no less.

@matt @ariadne (self-plug:) here's how removing a junk drawer libraries looks like: https://github.com/FRRouting/frr/pull/8508

I also think we should maybe move the "modularize and use dlopen() a bit more" slider a bit further out; and maybe there's room there for DX improvement as well (dlopen/dlsym are… clunky…). If the decision to include features can be made by installing packages, Debian doesn't _need_ to do "just the features required", it's the end user doing that with more and smaller packages.

@erincandescent @snowfox indeed CLOCK_TAI works by setting CLOCK_REALTIME plus the (integer) kernel TAI offset…

…but I'm a strong believer in incremental steps and I'd really like to see more software use CLOCK_TAI (as appropriate), and tackle representation of leap-smearing separately (because these things don't block each other)

The thing more concerning to me is filesystem support for TAI timestamps 😩