nhoughto

True you could rotate by persisting the old value and complicate your lookup/join process, not my idea of an acceptable solution but yep totally possible and worth it for some set of tradeoffs.

Yep have used an approach just like that, worked quite well if you have a strong pattern to easily translate from one to the other. Gives you an id with the right properties for internal use, efficient indexing etc, and in its encrypted form gives you the properties you want from an external identifier being unpredictable etc, all from one source id.

It is true that now your encryption key is now very long lived and effectively part of your public interface, but depending on your situation that could be an acceptable tradeoff, and there are quite a few pragmatic reasons why that might be true as has been described by other comments.

Edit: you can even do 64bit snowflakes internally to 128bit AES encrypted externally, doesn’t have to be 128-128 obvs

very neat! definitely will come in handy.

In startup/mvp land it is a genuine tension between shipping it and over engineering at different extremes. It is quite possible to correctly think “this is bad engineering” and still ship it and all of those decisions to be correct. Bootstrapping and early stage code almost inevitably gets replaced so isn’t worth polishing too much. It feels totally wrong and requires some real soul searching for some engineering personalities but in the end it’s optimizing for the most important outcome, the actual business success.. speaking from exp of not doing a few times and then the whole thing failing..

Yep

Couple of, retrospectively, often almost incoherent sentences to capture top of mind state when I give up because it’s late.

I’ll write this gibberish comment here because I’ll definitely forget what I was doing and if the compile fails I probably won’t miss it!

Watch out firebolt.io sounds like CH has solved the ease of deployment problem!

That’s the cell architecture, so N data plane clusters aka cells, testing qualifies a cell to meet a cert perf level and you horizontally scale out more cells to meet demand.

Whilst hoping a single customer doesn’t exceed the limits of a cell =)

Interesting idea, naively that seems possible based on other non chess example prompts I’ve seen. Would be a great way to understand it’s tracking of state throughout the game

I feel that, I’m often doing a thing thinking “this is wrong it won’t work for xyz” but continue because I want it to work, only to give in to what I knew a day+ ago but refused to acknowledge. It would definitely be more efficient to listen to.. myself, and kill things early.

Yep we talked to FE and they were great, but most selling processes require doco, finances, code review, walkthroughs, hand holding, explanations etc. “write down all the shit you’ve just known or learnt in the last 8 years” to make some multiple of revenue (not necessarily >1), with no guarantee of the sale closing and having to repeat.

Too. Hard. That plus the complexity of other things in our lives to deal with means that some $ just to see through a sale isn’t worth it.

The software is the thing we built and a testbed which we cut our teeth on, and learnt so much, took that knowledge and folded into other newer projects an incredible platform for learning and iteration, but we’ve moved on to bigger and better already so don’t too feel bad about turning it off (it was our first baby tho..).

Hit its effort vs scale limit and we’ve got more pressing things to spend time on. We could grow it but the result isn’t worth the effort compared to cost benefit of other endeavors we’ve got on the go (big tech jobs) and more recent time needs (young families).

Learnt a bunch across so many dimensions and set us up for ongoing success with that knowledge, but this specific thing has no future and selling it appeared too hard.

It was on autopilot for sure but that baked in an assumption that customers self solved, and had no new needs. We felt bad that we were delivering a decaying service to users in silence, users could use an alternative and get better service for their $ (in theory) and we would stop taking $ for what we see as delivering a subpar result.

We built a tool that does $5k/month which we are _shutting_ down today (end of 2022) after 8 years. Kind of the opposite but thought I’d share.

Show HN: https://news.ycombinator.com/item?id=8669122

Great details! Why only half the time though? What is the behavior the rest of the time?

Aw I was reading this thinking I wonder what incredible result it came up with! And bam, didn’t work! I guess that I was surprised it didn’t work is a testament to the other amazing results.

Yeah good point, not something I’d properly thought about.

Same in SF, I assumed it was because of the homelessness problem. Seems more likely than shoplifting gangs..

This looks handy, better ergonomics than strace to just hook into http requests of a running process.

I wonder how it works with TLS if it’s working at the socket level..

depending on your origin and your users, having TLS terminate / be negotiated at the edge should _reduce_ your connection setup cost, by reducing RTT time for the handshake to the end user (typically the slowest bit / longest tail).

If you have 1 origin region/server and globally distributed users, in the data shown the RTT from Sydney could be 1000ms, so TLS negotiation of 3 roundtrips could be 3000ms. If you terminate TLS at the edge that could be order of magnitude less.. not more? depends on your setup though.

Did a bit of testing about how to get files from a remote endpoint unpacked on disk the fastest, most interesting part was developing the method. Some good ideas on this thread I hadn’t thought off to test too.

https://nhoughto.github.io/blog/posts/2022/03/09/caching/

Never heard of the #1, Honor Magic4 Ultimate, but it looks like it aims for camera quality at the cost of everything else. iPhone looks like a much better set of tradeoffs at #2!

Do you need Netty in a virtual thread world? Imo Netty made non blocking IO in Java tractable.. but virtual threads does it better and more broadly, so what role does netty play now? What other than thread efficiency does it bring that can’t be achieved more easily now?

I’ve used jib and bazel and that’s exactly what they do, both are language agnostic and push files around. Jib has a java bent but not a required part of it.

I can totally see people using Depot bc it’s way easier and more obvious, works in the obvious way, and that is how things work today. It doesn’t challenge you to think, why the hell do I need a super privileged process with magic Dockerfile incantations just to take a tar of files and add another file to it? With some metadata? Docker has created some weird defaults.

container builds for services, compiled/packaged components you want to spin up somewhere, often the Dockerfile is very simple, use some base image, add config and your binary or packaged artifact (jars, minified JS etc) and done.

Often the complexity is (or should be) in the shared base not the individual images you build per commit or PR merge.. for those simple images using something like Jib (bazel can do it too..) where it just constructs the image in user land by adding files to the tarball. I imagine this works for arm binaries from x64 too as long as you can cross compile.. how do you feel about these libraries that make simple images waaay more accessible? No docker required.

I always thought go needed more GC knobs, good that they added this one and the strong reasoning behind it makes sense. Impressive go has got this far with just one knob!

The reducing customer friction arms race means if you can create a process that gives them the keys earlier or more “easily” you win, so if that process has an edge case where one in few hundred thousand gets arrested that might be seen as a net win, not how id design it but others have different tradeoffs!

No mention of if it’s force compression or not. Normal Btrfs compression can be unsuitable for some workloads where the beginning of files doesn’t compress but the rest does, Btrfs won’t compress the file if it appears pointless. Confused me when I tested it and can make a big difference!

https://btrfs.readthedocs.io/en/latest/Compression.html

Virtual threads preview! The beginning of a big change to java!

Yeah the CI case is really interesting, it’s generally reproducible and declarative so a good fit that way, and time waiting for things to start is a big deal in CI.

Another use case I was thinking of was stateful compilers like scala where warming up the compiler is expensive, often a CI task too.

also interested in the upper limit of a micro vm, like how big can it get? 64gb memory? not really micro any more and maybe a traditional VM would be a better fit.