HN user

kbaker

1,410 karma

Embedded systems engineer + software developer... My 'full stack' means PCB design and layout, RF + RFID, components + sourcing + product design (even some mechanical), kernel dev + bare metal embedded OS distros, add more layers of C, Python, Java, or .NET to tie it all together, then a nice-looking web frontend to top it off. Lots of fun to be had at every level!

send me email! username at gmail. [ my public key: https://keybase.io/kbaker; my proof: https://keybase.io/kbaker/sigs/sGOx8W59UuZWbo2z0B_5fbOKqvu0qyn42orx8wi2x_I ]

Posts1
Comments382
View on HN

We have (had?) some ticks in our backyard and I came across these which I thought was a clever attack angle: tick tubes.

Permethrin-soaked cotton balls in a tube, mice find them and build nests out of the freely available cotton, ticks that the mice have gathered while walking around die when they come back to the nest.

(For the unaware, OP above is the article author.)

As a long time user of Bitbake and Yocto, and watcher of Yoe Linux... I kind of have to respectfully disagree with the approach.

One look at the Python or Node packaging ecosystem, and you can see how difficult trying to integrate those in a 'sane' way in embedded, with repeatability and security in mind, nevertheless wrangling something like C/C++ dependencies and native packages in a qemu-cross (or binfmt emulation) environment.

I feel like Bitbake and the wider Yocto ecosystem has essentially 'solved' cross compiling. Sure there are the incredibly complex codebases like Chromium that require lots and lots of study and patience, or esoteric compilers, etc. but for most applications I feel that especially AI tooling can write up a good basic recipe for integration with Yocto.

The unfortunate thing about AI tooling is Kernighan's law (where debugging is twice as hard as writing it the first time.) Especially in Embedded Linux, where 99.99% of the product code is written by others, trying to figure out where the AI didn't quite get it right or missed something can break things unexpectedly and impossibly for the unaware developer to fix, even breaking at runtime. So the build environment has to be simple and predictable. I think Yocto/Bitbake already strikes a good balance here, with other nice things like offline builds, repeatable builds, sstate caching across machines, PRbuild servers... things useful for big teams, so consider those as well.

Although, if someone does a 'uv'-like rewrite of Bitbake into Rust with the same feature set but faster, I am all for it...

Maybe, having Yoe or some other centralized distro make specific opinionated choices and then provide an open sstate feed, working inside Bitbake, could get a lot of the speed and customizability gains back without a big rewrite effort.

Almost all retail RFID tags are on hanging labels, like with the price, or a sticker on the item. Although I did find one inside a pillow once.

A huge number of items at Walmart, Kohls, Target, Academy, Old Navy, and many other stores now (those are just the ones I've seen in store.)

Look for the 'EPC' logo, GS1 is the same standards body that controls the UPC barcode numbering.

https://www.gs1.org/standards/rfid/guidelines

Though - you don't want to use those types for this application, they are too long distance / not selective enough, and the readers are expensive.

Buy a big pack of NFC stickers instead, or print up some QR codes.

The GSD tool (get-shit-done) automates a very similar process to this, and has been mind-blowing for larger projects and refactors.

https://github.com/glittercowboy/get-shit-done

You still need to know the hard parts: precisely what you want to build, all domain/business knowledge questions solved, but this tool automates the rest of the coding and documentation and testing.

It's going to be a wild future for software development...

The Far Side is the only place in the Earth Moon system where you can hide military hardware and basically disappear. No optical tracking, no radar, no interception.

What prevents someone from sending a Lunar-orbiting imaging satellite to image everything on the Far Side? The Lunar Reconnaissance Orbiter has already been imaging the Far Side for over a decade.

I agree with your general points about it being a difficult location to get to, but if it's possible to put regular satellites in Lunar orbit, surely its possible to park some warheads too just in case...

Hi, curious, did you know about OpenRouter before building this?

OpenRouter provides a unified API that gives you access to hundreds of AI models through a single endpoint, while automatically handling fallbacks and selecting the most cost-effective options. Get started with just a few lines of code using your preferred SDK or framework.

It isn't OpenAI API compatible as far as I know, but they have been providing this service for a while...

That would be a fun project. Capture some WiFi geolocation data and rebroadcast it later with an ESP32 that switches its BSSID/SSID/frequency/transmit power to match an existing fingerprint.

And then see if you can be magically transported somewhere else.

But not every email provider would support this new (from scratch) protocol either?

Just don't see the need to reinvent OAuth but with a reduced scope for just email validation. Just add a happy path for this into OAuth itself?

This section

https://github.com/WICG/email-verification-protocol/blob/mai...

could easily be done by malicious JS, an ad script, or the website itself, and then as the RP gets the output of 6.4) email and email_verified claims.

I'm guessing that this proposal requires new custom browser (user-agent) code just to handle this protocol?

Like a secure <input Email> element that makes sure there is some user input required to select a saved one, and that the value only goes to the actual server the user wants, that cannot be replaced by malicious JS.

Why is the solution not OAuth/OIDC?

Or maybe creating some sort of reduced OAuth "Anonymous-Site-Verifying-Your-Email-Exists" flow?

Lol. I got perma-banned for violating rules under my alt accounts.

But I don't have any alt accounts...??? Appeal process is a joke. I just opted to delete my 12 year old account instead and have stopped going there.

Oh well, probably time for them to go under and be reborn anyways. The default subs and front page has been garbage for some time.

Yeah, I see the comments down below in pager.c which explain it a bit better. I guess I thought its behavior was more like PERSIST by default.

    **   journalMode==DELETE
    **     The journal file is closed and deleted using sqlite3OsDelete().
    **
    **     If the pager is running in exclusive mode, this method of finalizing
    **     the journal file is never used. Instead, if the journalMode is
    **     DELETE and the pager is in exclusive mode, the method described under
    **     journalMode==PERSIST is used instead.
So I guess this is one of the tradeoffs SQLite makes between extreme durability with (PERSIST, TRUNCATE, or using EXTRA) vs speed.

I know we have used SQLite quite a bit without getting into this exact scenario - or at least the transaction that would have been rolled back wasn't important enough in our case, I guess when the device powers down milliseconds later to trigger this case we never noticed (or needed this transaction), only that the DB remained consistent.

And it seems like if DELETE is the default and doesn't get noticed enough in practice that it needs to be changed to a different safer default (like to PERSIST or something,) I guess it is better to have the speed gains from reducing that extra write + fsync.

But, now I guess you know enough to submit better documentation upstream for a sliding scale of durability, I definitely agree that the docs could be better about how to get ultimate durability, and how to tune the knobs for `journal_mode` and `synchronous`.

OK, interesting, I think I see... So you are asking about if SQLite opens and finds a not-committed rollback journal that looks valid, then it rolls it back?

I was more curious so I looked at the code here:

https://sqlite.org/src/file?name=src/pager.c&ci=trunk

and found something similar to what you are asking in this comment before `sqlite3PagerCommitPhaseTwo`:

    ** When this function is called, the database file has been completely
    ** updated to reflect the changes made by the current transaction and
    ** synced to disk. The journal file still exists in the file-system
    ** though, and if a failure occurs at this point it will eventually
    ** be used as a hot-journal and the current transaction rolled back.
So, it does this:
    ** This function finalizes the journal file, either by deleting,
    ** truncating or partially zeroing it, so that it cannot be used
    ** for hot-journal rollback. Once this is done the transaction is
    ** irrevocably committed.
Assuming fsync works on both the main database and the hot journal, then I don't see a way that it is not durable? Because, it has to write and sync the full hot journal, then write to the main database, then zero out the hot journal, sync that, and only then does it atomically return from the commit? (assuming FULL and DELETE)

If the directory containing the rollback journal is not fsynced after the journal file is deleted, then the journal file might rematerialize after a power failure, causing sqlite to roll back a committed transaction. And fsyncing the directory doesn't seem to happen unless you set synchronous to EXTRA, per the docs cited in the blog post.

I think this is the part that is confusing.

The fsyncing of the directory is supposed to be done by the filesystem/OS itself, not the application.

From man fsync,

    As well as flushing the file data, fsync() also flushes the metadata information associated with the file (see inode(7)).
So from sqlite's perspective on DELETE it is either: before the fsync call, and not committed, or after the fsync call, and committed (or partially written somehow and needing rollback.)

Unfortunately it seems like this has traditionally been broken on many systems, requiring workarounds, like SYNCHRONOUS = EXTRA.

~~~~But your VM TPM won't be signed during manufacturing by a trusted root. No attestation.~~~~

OK I take it back, privacy is one of their specified goals:

Note that the certificate chain for the TPM is never sent to the server. This would allow very precise device fingerprinting, contrary to our privacy goals. Servers will only be able to confirm that the browser still has access to the corresponding private key.

However I still wonder why they don't have TLS try and always create a client certificate per endpoint to proactively register on the server side? Seems like this would accomplish a similar goal?

The Timmy Trap 11 months ago

Seems like this is close to the Uncanny Valley effect.

LLM intelligence is in the spot where it is simultaneously genius-level but also just misses the mark a tiny bit, which really sticks out for those who have been around humans their whole lives.

I feel that, just like more modern CGI, this will slowly fade with certain techniques and you just won't notice it when talking to or interacting with AI.

Just like in his post during the whole Matrix discussion.

"When I asked for examples, it suggested the Matrix and even gave me the “Summary” and “Shortening” text, which I then used here word for word. "

He switches in AI-written text and I bet you were reading along just the same until he pointed it out.

This is our future now I guess.

I could hope for a future PoE-over-Data Line (PoDL) version using an 18 AWG twisted pair that would work for this, providing something like 48V @ 3 or 4 A, and 10BASE-T1L for data. Hopefully a standard way to do this gains traction.

The existing limitation is with the 2x23 AWG (or 4x23 AWG) of Cat5e/6/6a not providing a lot of current-carrying capability at a safe voltage.

I use Claude through OpenRouter (with Aider), and was pretty amazed to see that it routes the requests during the same session almost round-robin through Amazon Bedrock, sometimes through Google Vertex, sometimes through Anthropic themselves, all of course using the same underlying model.

Literally whoever has the cheapest compute.

With the speed that AI models are improving these days, it seems like the 'moat' of a better model is only a few months before it is commoditized and goes to the cheapest provider.