ahlCVA

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.

Barcode fonts have been around for ages. But what's cute about this one is that it can calculate the EAN13 checksum on its own.

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.

This is a per-credential setting, so you can have your SSH signing key be a no-touch key and still use touch confirmation for everything else.

(see "uv" option here https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-cl... - the -sk key types in SSH are just a clever way of abusing the FIDO protocol to create a signing primitive)

For what it's worth: You can set no-touch-required on a key (it's a generation-time option though).

There is also a relatively modern capability-based kernel in the L4 family of microkernels, called Fiasco.OC: https://os.inf.tu-dresden.de/fiasco/overview.html

There are also a bunch of components for building a functional userspace (such as L4Re or Genode).

SNI leakage is what encrypted client hello (ECH) tries to solve: https://blog.cloudflare.com/announcing-encrypted-client-hell...

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.

Relevant SSC blog post: https://slatestarcodex.com/2015/01/31/the-parable-of-the-tal...

Starting from very similar observations but drawing the causality arrow in the opposite direction (alignment follows from talent).

Previously: https://news.ycombinator.com/item?id=38664729

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.

Press release: https://www.hopkinsmedicine.org/news/newsroom/news-releases/...

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).

My favorite bit of alternate history computer interface standards is UPAMD (https://en.wikipedia.org/wiki/Universal_Power_Adapter_for_Mo...) - essentially what USB-C/USB-PD ended up being but using CAN for communication and a pogo-pin-based connector.

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.

> I also liked the fact that Btrfs is probably super well tested in the Linux kernel by now.

btrfs has certainly been around for longer, but in my (embedded systems only) experience, EROFS has been pretty solid - it's slowly being picked up by Android, so it is definitely seeing a lot of use in the wild (probably surpassing btrfs by the number of installations already).

> btrfs.openfreemap.com just a public Cloudflare bucket, no idea why it might be slow.

I'm getting 30 MiB/s (on a gigabit uplink) - not great, not terrible. A .torrent would be nice but I guess outside of being on the HN front page full-planet downloads by different people won't synchronize enough for this to be useful (and using web seeds is problamtic in its own right with small-ish chunks).

This sounds like a perfect application for EROFS[1]. While it comes from an embedded systems background, it has seen some usage in container use cases and is moving towards a general "mountable tar" application. It would also avoid the tedium you have to go through in shrink_btrfs.py because you can just generate the image out of a tree.

I wanted to give repackaging the btrfs image a shot but the download was pretty slow - I assume your server is getting HN-hugged a bit so I didn't want to make it worse and stopped the download.

[1] https://erofs.docs.kernel.org/en/latest/index.html

I feel the same, but I've never actually talked to anybody about it since it felt like such a strange thing to say. Thanks for letting me know I'm not alone!

Fascinating that somebody is using Swift "in production" for that!

I work on small-ish embedded Linux systems and I've been looking for an alternative to C for a long time. Rust does not fit the bill, both because I don't enjoy the ergonomics of it (but I could get over that were it not for the other issues) and because the binaries are huge, so unless you go for a busybox-style multicall binary (and even then) you'll be wasting a lot of space. Both the standard size reduction techniques and splitting out things into shared objects (the ABI instability is not an issue on an embedded system which always gets compiled as a whole anyway) don't really move the needle compared to what you can achieve using plain C.

I've been meaning to give Swift a shot for applications like this. From what I've seen I had assumed that it would have less of a tendency to monomorphize everything (like Rust and C++ like to do when you use them idiomatically), leading to less binary size bloat.

You also mention binary size, but in relation to a library - is it that the absolute cost of including the library in the image is too high or is there a per-binary effect here as well?

Could you maybe share some of your experiences with Swift on embedded Linux in the context of that project? What is working well, what are the warts? What kind of distribution (like buildroot, Yocto, ...) are you using?

Sorry for the ton of questions, it's just something that has been on my bucket list for quite a while and it very exciting to hear that somebody is already doing this.

As a connoisseur of serialization formats, this is intriguing - I wasn't aware there was a schemaful version of msgpack once, and an ad-hoc search doesn't reveal any leads.

Can you point me to some information on how that older format worked?

It was just a bad fit for the problem at hand. It was picked mainly because there were a bunch of Elixir backend devs in the organization that were out of work and every problem looks like a web service (or any other system architecture you're familiar with) if you want it badly enough. There was a bunch of hardware interaction that ended up getting externalized into a separate C++ component that exposed a gRPC interface towards the Elixir component both because of Conway's Law and because nobody wanted to (or knew how to) write NIFs and deal with blocking operations on the Erlang side.

A two-digit number of these devices was meant to form a cluster of sorts and using Erlang clustering sounds like a nice solution for that until you realize that the base load of the full mesh that this implies is high enough to use a meaningful chunk of the device's resources.

I once used CRIU to implement the hacky equivalent of save-lisp-and-die to speed up the startup process of a low-powered embedded system where the main application was misguidedly implemented in Erlang and loading all the code took minutes each time the device started. It worked better than it should have (though in the end it wasn't shipped because nobody (except the customer) cared enough about the startup behavior and eventually the product got canned (for different reasons)).

> find an old daisy-wheel printer

I'm definitely on board with the analog approach, but this is interesting. What's the reason for recommending a daisy-wheel printer compared to other printing technologies? Is it just that the deformation caused by the impact of the type serves as additional redundancy or is the ink (or its adhesion to the paper) somehow superior to other printing processes in this regard?

This is a frequently-touted solution, but now somebody compromising printer.lan.example.com can impersonate auth.lan.example.com, which isn't great either.

> A MITM attacker can arbitrarily delete messages from a connection before the secure channel is established, as sequence numbers are only validated once the channel is established and arbitrary messages are allowed during the handshake, allowing them to manipulate the sequence numbers. Depending on the cipher being used, once the secure channel is established, the attacker can then use the manipulated sequence numbers to delete messages sent immediately after the channel is established.

(https://github.com/golang/go/issues/64784)

OpenSSH also has released an update: https://seclists.org/oss-sec/2023/q4/291