It seems like it doesn't do this for Code 128 (possibly because it is variable-width?). It definitely works with EAN13 though - I tried it locally using only the TTF file.
This isn't without downsides though: As somebody with a niche technical hobby, it is hard for me to order from many suppliers because they understandably don't want to deal with consumer protection laws and thus exclude B2C transactions outright ("Verkauf nur an Gewerbetreibende").
I would be fine with waiving my right to returns but this is not possible on purpose, so my only options are to shop somewhere else (often not possible) or found a company (not possible because it would be Liebhaberei - "Running a company without intent to make profits").
Whenever one of these vulnerability apocalypse posts comes along I cannot help but think of the Litany of Gendlin:
What is true is already so.
Owning up to it doesn't make it worse.
Not being open about it doesn't make it go away.
And because it's true, it is what is there to be interacted with.
Anything untrue isn't there to be lived.
People can stand what is true,
for they are already enduring it.
I cannot wrap my mind around why people think finding vulnerabilities is bad. The code already was broken before somebody published the vulnerability. The difference now only is that you know about this.
Imagine somebody finding a flaw in a mathematical proof and everybody being sad because a beautiful proof got invalidated rather than being glad future work won't build on flawed assumptions.
I get that the rate of vulnerability discovery can be a burden, especially for people doing FOSS in their spare time, but the sustainability problem with that has always existed and only gets exacerbated by the vulnerability stuff, but the latter isn't the cause you need to make go away.
Apple implements the USB-C/USB PD specs to a t and is unforgiving if you don't do either.
At work, our quick test for if a device implements USB PD correctly is to plug it into an Apple power supply (optionally with a PD protocol sniffer in line). If it doesn't work (either no/intermittent VBUS or the wrong VBUS), it's always been the case that the device is doing something wrong.
It can be annoying but strictly speaking their fault.
Obviously the two aren't the same (especially given the need to do routing), but I've always found it amusing that in the systems world, capability-based systems (i.e. making it impossible to address things you aren't allowed to access) are gaining traction while the philosophy in the networking world seems to be going in the opposite direction (make it possible to address everything, i.e. IPv6 vs. NATted IPv4, then add filtering).
Calling publishing API docs "open-sourcing" is a bit hyperbolic, but as token gestures go, it's at least worth a little bit.
I'm not familiar with those devices in particular, but I wish vendors would take steps to make life easier for after-markt firmware developers especially once devices go EOL by doing things like proactively dropping a GPL tarball and giving people a way to disable secure boot locks on devices that have them.
It's still not perfect since you're still leaking information about the privacy set implied by the outer ClientHello, but this possibly isn't much worse than the destination IP address you're leaking anyway.
Whenever people complain about the energy usage of LLM training runs I wonder how this stacks up against the energy we waste by pointlessly redownloading/recompiling things (even large things) all the time in CI runs.
While this leaves a lot to be desired as a window manager, it illustrates one of my main gripes about the Wayland ecosystem: By effectively bundling the window manager and X server, it makes it much harder for more niche/experimental window managers to come about and stay alive. Even with things like wlroots, you have to invest a lot more work to get even the basics working that X11 will give you for free.
I see reproducible builds more as a contract between the originator of an artifact and yourself today (the two might be the same person at different points in time!) saying "if you follow this process, you'll get a bit-identical artifact to what I have gotten when I followed this process originally".
If that process involves Docker or Nix or whatever - that's fine. The point is that there is some robust way of transforming the source code to the artifact reproducibly. (The less moving parts are involved in this process though the better, just as a matter of practicality. Locking up the original build machine in a bank vault and having to use it to reproduce the binary is a bit inconvenient.)
The point here is that there is a way for me to get to a "known good" starting point and that I can be 100% confident that it is good. Having a bit-reproducible process is the no-further-doubts-possible way of achieving that.
Sure it is possible that I still get an artifact that is equivalent in all the ways that I care about if I run the build in the exact same Docker container even if the binaries don't match (because for example some build step embeds a timestamp somewhere). But at that point I'll have to start investigating if the cause of the difference is innocuous or if there are problems.
Equivalence can only happen in one way, but there's an infinite number of ways to get inequivalence.
For me as a developer, reproducible builds are a boon during debugging because I can be sure that I have reproduced the build environment corresponding to an artifact (which is not trivial, particularly for more complex things like whole OS image builds which are common in the embedded world, for example) in the real world precisely when I need to troubleshoot something.
Then I can be sure that I only make the changes I intend to do when building upon this state (instead of, for example, "fixing" something by accident because the link order of something changed which changed the memory layout which hides a bug).
Buildroot has package-parallel builds when using BR2_PER_PACKAGE_DIRECTORIES (see https://buildroot.org/downloads/manual/manual.html#top-level...). It's for some reason still marked as experimental in the docs but it has been solid for me for many years.
The lack of dependency tracking isn't great but other than working around it like you described just using ccache has worked pretty well for me. My Buildroot images at work do full recompiles in under 10 minutes that way.
Meanwhile the Yocto projects I've worked on used to have a ton of chaff that causes partial rebuilds with trivial changes to take longer than that. This probably isn't an inherent Yocto/BitBake thing but the majority of Yocto projects out there seems to take a very kitchen-sink approach so it's what you'll end up having to deal with in practice.