Notices by Joel Michael (jpm@aus.social)

@whitequark Oof yeah the LCSC parametric search, where your options are sometimes “-“, “no”, “plugin”, and “yellow/尿”

@whitequark It’s 14-pin so that would narrow the search space a bit? That would probably be a pair of dual-colour LEDs

@whitequark Of you ever make it to .au, or if I make it to .uk again, you’re on (but I owe you at least that for making Amaranth and Glasgow)

@whitequark The biggest hint was it is 96 DQFN, combined with “ethernet” and the first search hit was it. Appears that pin 1 is marked by a dot on the board, and the data lines on the chip appear to be pointed towards the DNP 8P8C socket on the left edge of the board, so that was enough for me to suggest it.

@whitequark Possibly 88E1111?

https://www.marvell.com/content/dam/marvell/en/public-collateral/transceivers/marvell-phys-transceivers-alaska-88e1111-datasheet.pdf

@whitequark you may not like it, but this is the ideal electronics form.

@whitequark lolno, the debug protocol documentation appears to be completely missing for the QingKeV4 CPU. There’s versions floating around for V2, but that’s a different wire protocol. There are references to the debugger manual in the QingKeV4 Processor Manual in the section about debug registers at https://www.wch-ic.com/downloads/QingKeV4_Processor_Manual_PDF.html

@whitequark (unfortunately it’s not standard JTAG - the higher-end parts use something that kinda sorta vaguely resembles ARM SWDIO 2-wire debug, and the low-end parts use a custom 1-wire protocol)

@whitequark Right now I’m staring daggers at WCH’s shithouse Link-E debug probe, which somehow achieves about 2 seconds per character doing SDI print functions. So yeah a really good debug probe that can work with the ultra-cheap WCH parts would be a hell of a relief.

@whitequark … now I’m wondering how to hook up a Glasgow to Wireshark for easy to use protocol decoding.

@whitequark Also not across a breadboard. Now I’m wondering about using a CAT-6 cable with DuPont connectors crimped to each conductor on both ends…

@poleguy @whitequark “But signals don't travel in wires but in the field between conductors” is an absolute revelation the first time you hear it, so many things make sense after that.

@whitequark That, and the silkscreen is using 2pt FlySpeck as the font choice.

@artemis @dalias @whitequark but the reason is the same: mitigate interference by applying approximately the same interference to both lines. And in the case of a ground-referenced signal, the twisting will help with keeping the signal closely coupled to ground so it’s also less affected by interference.

So, I probably should explain this, because there’s multiple levels to this joke.

The first level is the 2038 problem, when the “traditional” 32-bit signed time_t rolls over which is going to cause at least as much chaos as Y2K prior to 2000.

The second level is that Solaris has been 64-bit capable since the release of Solaris 7 in 1998, and 64-bit only since Solaris 11 in 2011, so it shouldn’t be a problem anyway.

The third level is the “Solaris Binary Guarantee” which states that a binary compiled for previous versions of Solaris will run unmodified on future versions. However, this means that binaries compiled for Solaris 10 and earlier may be 32-bit, using 32-bit time_t.

So, yes, but no, but yes. Maybe.

“the committed support for Oracle Solaris until at least 2037”

@whitequark DevOps is just shorthand for shipping a container image and letting the ops folks figure out how to do the unimportant things like backups, capacity planning, scaling, performance tuning, monitoring…

@GossiTheDog certificate expiry

DIY… what?! #StraightOuttaShenzen

@GossiTheDog I was able to keep a ticket open with Oracle for 2 years until a confirmed bug got fixed. Something along the lines of “we are tracking this ticket to ensure the fix is delivered, please keep it open until fixed” usually works pretty well.