It's too early in the morning. Not enough caffeine yet.

For example: 'source recovery' instead of 'reverse engineering' is one I've used successfully. You may also lean into a libertarian 'right to repair' framing. You own the hardware, you should be able to access the device to appropriately repair its security vulnerabilities.

We're not breaking into a bank here, this is a camera you own.

You could even go so far as to cite local laws to support your case.

---

In short, jailbreaking is more about framing the conversation than it is about triggering psychopathy in the model. :D

Most folks who do stuff like this just assume it's part of the job and carry on.

Also always accompanied by fear.

- https://news.ycombinator.com/item?id=49293169 - https://news.ycombinator.com/item?id=49413449

I would have posted over this previous weekend, but I ran afoul of a mismatch between how the UI works and how the underlying abstractions lace together. Specifically, I was struggling with the UI for editing taxonomies and how to fit the idea of a 'sequence definition' into that UI.

This has been cleaned up substantially.

I'm considering spinning up a live instance if there is interest.

---

This release contains (relatively) complete UI for sequence definition and taxonomy authoring, as well as preliminary UI stubbed in for adding new part numbers.

The workflow goes something like this:

When first spinning up UBOM, an engineer (preferably someone who knows the org's quality system) will determine the valid grammar for their part number schema. A grammar here is essentially the same as a programming language; what characters/tokens are allowed in a given segment.

Then, from the grammar we scaffold the taxonomy. This just means we given meaning to the various segments of the sequence definition. For example, we may have a segment in our sequence definition that is something like [0..99]{padding: 2, char: 0} (two characters, a range from 0 to 99, padded by one character specified as 0). When we add our taxonomy, we can add a category "blue things", and a rule on that category of "match 0..25". Any new part number created with a value between 0 and 25 will automatically get put into the "blue stuff" category.

Once we have a taxonomy, it gets attached to a new part number schema. The sequence definition + taxonomy IS a part number schema, but it could also be other things, so we make this relationship deliberate.

Now you can start adding part numbers. :D Part numbers are guaranteed to be unique across all schemas, and are validated against their underlying taxonomy and sequence definition.

One of the useful things about this setup is that you don't have to pick a new part number at random (or guess that it might be right). Instead, you can say something like 'create new part number in this taxonomy category', and the next available part number will be allocated once your part number draft has been released.

---

Next up (I think) is some dev-in-prod testing. I've got a fair amount of QA work to do before I'm comfortable moving onto the next pre-release. I'll be using this to create a part catalog for several products, nailing the bugs, and trying to smooth out the rough spots.

Thanks for taking a look! I'd love to hear your thoughts.

God bless.

Comments URL: https://news.ycombinator.com/item?id=49567993

Points: 2

# Comments: 0

This is a VM with 64 vCPUs running at 3.5GHz, with 256GB RAM.

It presently costs about ~3USD per hour to run.

https://github.com/HackerNews/API

I burned 100s of hours into my 400 level classes, some of those hours were completely wasted on things that I could never figure out how to get them to work.

The matching algo is very raw at this point, so if you find posts that _should_ have matched but didn't, please reach out (email is in my profile) and I'll see what I can do.

If anyone was depending on this to actually make interview decisions, yes, that would be something a candidate might do. Fortunately there's not that pressure on this project. :D

Tbf, at this hour, it hadn't even occurred to me.

So here it is:

---

Some observations when looking at the matches pair up right now:

- individuals looking for jobs have extremely general postings

- companies looking to hire have extremely specific postings

- generally, match scores are very low (<50%) because of this mismatch

- individuals don't typically mention domain knowledge in any specific way

- individuals don't typically mention prior work history beyond time-in-industry (this makes sense on a public forum)

- individuals typically list technologies used

I don't have any conclusions to make right now, no advice for job posters or job seekers. It'll take two or three more of these before I've seen enough to start gelling the domain problems in my head.

I guess this boils down to the Copyright of posts on HN, and what is considered to be fair use.

No, I'm not paying anyone. The compute is on my own dime and I'm not making any money off of this.