bittermandel

This seems to only be for a few of the offices as well. A famous project (at least in Swedish news) earlier this year introduced airgapped Kimi-based models for usage, but it got paused.

I should do a write-up! Maybe you'll see it posted here soon. We could basically find nothing online...

By experience, getting Firecracker to run well on M-series macs is quite the undertaking. I'm not at all surprised Encore decided to take this path considering their customer base!

At Lovable we decided to spend ~1 engineering month getting our sandbox infrastructure to be 100% runnable on Mac and on Linux with predictable builds using Bazel etc.

But we actively decided to take a different route than Encore and run nested virtualization, which on macOS means vfkit -> QEMU -> Kind + Firecracker vm(s). It's been invaluable to get the same development and testing tools on both platforms tbh.

This is exactly my experience at Lovable. For some parts of the organization, LLMs are incredibly powerful and a productivity multiplier. For the team I am in, Infra, it's many times distraction and a negative multiplier.

I can't say how many times the LLM-proposed solution to a jittery behavior is adding retries. At this point we have to be even more careful with controlling the implementation of things in the hot path.

I have to say though, giving Amp/Claude Code the Grafana MCP + read-only kubectl has saved me days worth of debugging. So there's definitely trade-offs!

I confused this with https://github.com/omcljs/om

I made this with Lovable as well, it's interesting how it's a bit more extreme in terms of where we are in 2035.

https://hn-frontpage-2035.lovable.app/

> The last JavaScript framework: Why we stopped at React 47 (overreacted.io)

I use this heavily to navigate the neondatabase/neon repo and it has been invaluable

Neon does a variant of this. The WAL goes through a Paxos consensus directly on NVMe, which then is transformed to page files and stored in Object Storage

Django was the whole start of my career and I still thank it for many of my opportunities. I started in 2012 to work with Django at Billogram, then founded a Django consultancy which lead me to work at King 3 years later.

Who knows where I would be today if not for Django!

I just tried this. HOLY CRAP its good. How did you achieve this? I'm very impressed.

Also: Please don't evolve the UI. Its perfect as it is

We're working on a Container Registry for https://molnett.com. We don't really want to use Harbour as we want to manage our own AuthN/AuthZ and are fully multi-tenant, so we decided to build our own on top of Distribution.

Going from Manifest to OCI is a bit tricky and performance for calculating total storage based on metadata is hard to get right. But the result is that we own our full registry implementation and can take it any direction we want. Quite happy with that!

I don't think you are wrong at all. As we are all founders with an OK salary and this is our area of expertise, so we're able to take advantage of our previous experiences and reap the benefits. We're probably uniquely positioned here.

I had massive issues at my previous employer with Bazel. They did not try to make Bazel work for non-SREs, which as you can imagine didn't work very well. So it's definitely not a silver bullet!

We should probably write a blog post about our setup!

I think this take is quite shallow and lacks insight into how one would actually build a somewhat complex technical platform.

We are not using a microservice pattern at all. I am not sure where you get that from. If anything we have several "macro services".

Our final setup is quite complex as we are building a literal cloud provider, but in practice we have a Go API, a Docker registry, a Temporal Worker and a Kubernetes controller. Whats complicated is everything else around it. We run our platform on bare-metal and thus have auxiliary services like a full-blown Kubernetes cluster, Ory Hydra + Kratos, SpiceDB, Cilium, Temporal Cluster + Workers and some other small things. We need to be able to test this locally to feel safe to release to production. And in turn our production environment is almost identical to our local environments.

None of that would be possible unless we've done something similar to what we have built today. Most companies cannot run their entire stack on their laptop, more unlikely that they could run a full cloud provider.

I firmly believe that us at Molnett(serverless cloud) going for a strict monorepo built with Bazel has been paramount to us being able to make the platform with a small team of ~1.5 full-time engineers.

We can start the entire platform, Kubernetes operators and all, locally on our laptops using Tilt + Bazel + Kind. This works on both Mac and Linux. This means we can validate essentially all functionality, even our Bottlerocket-based OS with Firecracker, locally without requiring a personal development cluster or such.

We have made this tool layer which means if I run `go` or `kubectl` while in our repo, it's built and provided by Bazel itself. This means that all of us are always on the same version of tools, and we never have to maintain local installations.

It's been a HUGE blessing. It has taken some effort, will take continuous effort and to be fair it has been crucial to have an ex Google SRE on the team. I would never want to work in another way in the future.

EDIT: To clarify, our repo is essentially only Golang, Bash and Rust.

I just used Sonnet 4 to analyze our quite big mono repo for additional test cases, and I feel the output is much more useful than 3.7. It's more critical overall, which is highly appreciated as I often had to threaten 3.7 into not being too kind to me.

Wouldn't Rook be a good solution? It's definitely proven in much larger settings than Minio, as it's just Ceph.

Big congratulations!

I really do hope that their OSS strategy does not change due to this, as it's really friendly to people who want to learn their product and run smaller deployments. It's (intentionally or not) really hard to run at a big scale as the control plane is not open-source, which makes the model actually work.

I'm right now working on the Managed Postgres offering for our European Serverless cloud provider, https://molnett.com/. We're building it around Neon and are happy with it so far, but are stumbling upon unforeseen issues like query modes (Thank you Pgx for not being compatible by default with PGBouncer).

Hope to launch it soon!

This is amazing! We built something similar at Jetstack based on Kata Containers, but it was running in Kubernetes itself.

This is exactly what I would love to build if I had the time <3

We're definitely heading in the right direction!

Our company's biggest remaining problem is finding a reliable IdP that isn't primarily for individuals, self-hosted or based on Active Directory. There are some alternatives, but they are mainly country-specific (like Freja) or not well integrated enough with e.g. OAuth. We've considered at some point to pivot our company to focus on a fully European IdP, as we feel it's a fundamental missing puzzle piece!

Odd, why was this post removed from the front page? There's older and less active posts there.