Hacker News: amboar

New comment by amboar in "How SQLite is tested"

amboar — Thu, 18 Dec 2025 05:49:56 +0000

I've become pretty enthusiastic about checklists.

In case it helps anyone else, I wrote a small tool that helps maintain and execute them:

It's just a shell script wrapped around $EDITOR and git. The intent is to write checklists in the style of github-flavoured markdown. It has some tricks such as envsubst(1) interpolation and embedding little scripts whose execution is captured alongside the execution itself.

Here's an example checklist that's fairly well-worn (though is somewhat dated):

https://gist.githubusercontent.com/amboar/f85449aad09ba22219...

Where checklist entries are commands I just copy/paste them into a shell session. Usually this is in a tmux split with the checklist on one side with a shell on the other.

Could more of it be automated? Perhaps, though when some of the steps fail for various reasons, I find it's easier to recover or repair the situation if I have been invoking them myself sequentially. The embedded script support enables progressive automation where stability of the results is demonstrated over time.

New comment by amboar in "Is Software the UFOlogy of Engineering Disciplines?"

amboar — Fri, 07 Nov 2025 20:46:30 +0000

As I haven't seen a link to it in the comments yet: A while back Hillel Wayne put some effort into resolving the question of "Is Software Engineering Real Engineering?" with the crossover project: https://www.hillelwayne.com/talks/crossover-project/

The conclusion he drew was that there's less difference than you might expect between software development and "traditional" engineering disciplines and that it's reasonable to consider software engineering a real engineering discipline.

New comment by amboar in "The Helix Text Editor (2024)"

amboar — Fri, 12 Sep 2025 11:36:28 +0000

[keys.select."space"] q = ":reflow"

has worked well for me, even if the reflow behaviour itself is sometimes frustrating

New comment by amboar in "Programmers aren’t so humble anymore, maybe because nobody codes in Perl"

amboar — Fri, 01 Aug 2025 11:57:59 +0000

gcc's __attribute__((tainted_args)) is pretty handy: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attribute...

New comment by amboar in "GCC 15.1"

amboar — Fri, 25 Apr 2025 14:59:24 +0000

Section J.1 _Unspecified_ behavior says

> (11) The values of bytes that correspond to union members other than the one last stored into (6.2.6.1).

So it's a little more constrained in the ramifications, but the outcomes may still be surprising. It's a bit unfortunate that "UB" aliases to both "Undefined behavior" and "Unspecified behavior" given they have subtly different definitions.

From section 4 we have:

> A program that is correct in all other aspects, operating on correct data, containing unspecified behavior shall be a correct program and act in accordance with 5.1.2.4.

New comment by amboar in "Git as a debugging tool"

amboar — Sun, 31 Mar 2024 04:24:50 +0000

Yeah, I have rerere turned on However, it's not directly beneficial for the process outlined. With what I wrote about you only solve a given conflict at the end of a complete bisect run, not at each bisection point inside a run. The bisect/cherry-pick process is only used to determine whether conflicts do or don't happen at a given upstream commit. Usually you will solve a specific conflict only once, regardless of whether rerere is enabled.

New comment by amboar in "Git as a debugging tool"

amboar — Sat, 30 Mar 2024 22:00:41 +0000

A handy trick I've developed is using`git bisect` to solve otherwise intractable rebase conflicts:

https://codeconstruct.com.au/docs/bisect-intractable-rebase-...

New comment by amboar in "Solar and wind to top coal power in US for first time in 2024"

amboar — Sun, 17 Dec 2023 06:55:27 +0000

Related, have something similar for the major grid in Australia and it's smaller counterpart in Western Australia: https://opennem.org.au/

New comment by amboar in "Our BMCs are not great at keeping accurate time"

amboar — Tue, 09 Aug 2022 15:07:25 +0000

OpenBMC supports SoCs from Aspeed and Nuvoton, and HP were/are working to add support for their GXP (iLO) SoC.

New comment by amboar in "Two startups tried to catch up to makers of advanced computer chips, and failed"

amboar — Tue, 11 Jan 2022 11:45:26 +0000

Ah, here's the circuit design equivalent of that story: https://twitter.com/dave_universetf/status/14734753486542684...

New comment by amboar in "Full key extraction of Nvidia TSEC"

amboar — Tue, 23 Nov 2021 09:33:22 +0000

One of my favourite talks is Decapping Chips the Hard Way by Adam Laurie and Zac Franken: https://youtu.be/0Z4aF-qiziM

That was 8 years ago

New comment by amboar in "OpenPOWER Foundation announces LibreBMC, a POWER-based, fully open-source BMC"

amboar — Tue, 11 May 2021 09:42:31 +0000

> It was eating characters, which is the second worst thing it could do.

Okay, that's interesting. Did you file a bug with your system's firmware provider or with upstream?

You can file it against obmc-console at https://github.com/openbmc/obmc-console/issues

> Digging into the source, I found a really wonky software buffer... which kind of blew my mind - since hardware buffers and flow control exist.

Yep, it's how OpenBMC provides the console via IPMI, Redfish, SSH and on the commandline, as well as routing the console out to the connector on the rear of the chassis.

> I don't remember if that was a case where python was somehow in the pipeline, but that was unfortunately very common in OpenBMC.

Generally there hasn't been any python in the console handling pipeline. That said, python, while especially slow on a BMC, was pretty important for getting the project off the ground.

At this point OpenBMC has been python-free for several years.

> I also had a lot of trouble getting the thing to honor the most basic settings, like baud rate

There's some nuance to this, as depending on your system design the console may be coming from the host to the BMC via Aspeed's Virtual UARTs (VUARTs). The way the VUARTs work is the BMC and host are connected to either end of the two FIFOs between the UARTs' APB and LPC/eSPI interfaces. As such there's no baud rate as no data is clocked out in RS-232 fashion - the data is transferred as quickly as either side can access their register interfaces.

This has caused issues in the past with control flow that lead to data integrity issues:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

> But it is harder to confidently place the blame on that one. Is it OpenBMC's fault that the software provides no clue as to where things are going wrong in the serial plumbing? Is it the AST2500's fault that designers are routing every serial line through it and making it impossible to eliminate as the cause while troubleshooting?

I agree it can be difficult to debug where things are going wrong in the console pipeline.

In concept a serial console should be simple, but when you bring in requirements like various kinds of SoL, it starts to get more complex.

New comment by amboar in "OpenPOWER Foundation announces LibreBMC, a POWER-based, fully open-source BMC"

amboar — Tue, 11 May 2021 04:59:32 +0000

> there is a lot about it that I won't miss, especially the way it handles serial communication

Out of curiosity, what were the issues you had with OpenBMC's serial communication?

New comment by amboar in "Speed of Rust vs. C"

amboar — Sat, 13 Mar 2021 06:22:04 +0000

I realise your post is an argument in favour of Rust over C for these things, but regardless, you might be interested in a WIP library I've started to solve most of the issues you outlined: https://github.com/amboar/shmapper#libshmap

New comment by amboar in "Clockwise/Spiral Rule"

amboar — Tue, 22 Dec 2020 12:48:32 +0000

> - braindamaged linking

I mean, it's simple, but brain-damaged?

> - "if (!pred(x) || a <= b && y)" for "if not pred(x) or a =< b and y"

I guess more parentheses would improve the clarity but your English translation suffers the same problem as the code

> the c pre-processor

> - a broken comment syntax (how do you comment out a region with comments inside?)

Use the pre-processor that you complained about

#if 0 ... #endif

New comment by amboar in "How io_uring and eBPF Will Revolutionize Programming in Linux"

amboar — Fri, 27 Nov 2020 06:44:35 +0000

As others have said, hacking it, certainly. But if you're not up for that and would like something more passive, read LWN.net (and possibly subscribe!)

New comment by amboar in "Code Health: Make Interfaces Hard to Misuse (2018)"

amboar — Sun, 06 Sep 2020 11:56:41 +0000

Rusty's API scale captures this approach really well:

How Do I Make This Hard to Misuse? https://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html

What If I Don't Actually Like My Users? https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html

New comment by amboar in "Stop Memsetting Structures"

amboar — Sat, 27 Apr 2019 20:50:33 +0000

Use a packed struct (e.g. __attribute__((packed))). You may take a performance hit due to lack of alignment, but that's the judgement call

New comment by amboar in "Gaining control of BMC from the host processor"

amboar — Tue, 29 Jan 2019 13:30:40 +0000

Right; then it comes down to platform design and whether you can reboot the soc in a mode that both reopens the bridges and doesn't kill the host, though that's not relevant if you're accessing it from the UART debug interface.

FWIW the mitigation patch in OpenBMC turns off all the bridges early in u-boot to minimise the race window for system reset/AC cycles.

Obviously would be better if it was possible to avoid the race window entirely (i.e. bridges default to closed, can be strapped open by the platform designer, and opened as required by firmware). We had asked for hardware changes along these lines for future generations (but may need to push a little harder...)

New comment by amboar in "Gaining control of BMC from the host processor"

amboar — Wed, 23 Jan 2019 07:16:28 +0000

Something important to note is that this is largely a BMC firmware problem - the hardware can be securely configured to maintain CIA against the host, just sometimes it is not.