silasb

Gemini was a good laugh as well:

    Silas: I want to wash my car. The car wash is 50 meters away. Should I walk or drive?
    Gemini:
    ….
    That is a classic “efficiency vs. logic” dilemma.
    Strictly speaking, you should drive. Here is the breakdown of why driving wins this specific round, despite the short distance:
    ...
    * The “Post-Wash” Logic: If you walk there, you’ll eventually have to walk back, get the car, and drive it there anyway. You’re essentially suggesting a pre-wash stroll.
    When should you walk?
    …
    3. You’ve decided the car is too dirty to be seen in public and you’re going to buy a tarp to cover your shame.

Seems pretty similar to https://github.com/radioactive-labs/chrono_forge which is what I found when I typed in "rails durable execution patterns" into Google. Have you seen this and if so, how do you think it compares?

moonlight / sunshine might work if you can't run it locally.

It'd be best with hardwired network though.

I'm not trying to take a shot at the OP, but I keep seeing posts labeled "Production-Grade" that still look more like pet systems than cattle. I'm struggling to understand how something like this can be reproduced consistently across environments. How would you package this inside a Git repo? Can it be managed through GitOps? And if we're calling something production-grade, high availability should be a baseline requirement since it's table stakes for modern production applications.

What I'd really love is a middle ground between k8s and Docker Swarm that gives operators and developers what they need while still providing an escape hatch to k8s when required. k8s is immensely powerful but often feels like overkill for teams that just need simple orchestration, predictable deployments, and basic resiliency. On the other hand, Swarm is easy to use but doesn't offer the extensibility, ecosystem, or long-term viability that many organizations now expect. It feels like there's a missing layer in between: something lightweight enough to operate without a dedicated platform team, but structured enough to support best practices such as declarative config, GitOps workflows, and repeatable environments.

As I write this, I'm realizing that part of the issue is the increasing complexity of our services. Every team wants a clean, Unix-like architecture made up of small components that each do one job really well. Philosophically that sounds great, but in practice it leads to a huge amount of integration work. Each "small tool" comes with its own configuration, lifecycle, upgrade path, and operational concerns. When you stack enough of those together, the end result is a system that is actually more complex than the monoliths we moved away from. A simple deployment quickly becomes a tower of YAML, sidecars, controllers, and operators. So even when we're just trying to run a few services reliably, the cumulative complexity of the ecosystem pushes us toward heavyweight solutions like k8s, even if the problem doesn't truly require it.

I've been looking at this for gunzip files as well. There is a rust solution that looks interesting called https://docs.rs/indexed_deflate/latest/indexed_deflate/. My goals are to be able to index mysql dump files by tables boundaries.

I 100% agree which has led me in saying "modules > microservices" for our onboarding documentation.

Doesn't "Buy, and buy from certified providers, simple. Manage identity centrally...." contradict each other?

Nice, I'm working in the same space as you (not opensource, personal project). We landed on the same solution, encoding the commands inside Golang and distributing those via SSH.

I'm somewhat surprised not to see this more often. I'm guessing supporting multiple linux versions could get unwieldy, I focused on Ubuntu as my target.

Differences that I see.

* I modeled mine on-top of docker-plugins (these get installed during the bootstrapping process)

* I built a custom plugin for deploying which leveraged https://github.com/Wowu/docker-rollout for zero-downtime deployments

Your solution looks much simpler than mine. I started off modeling mine off fly.io CLI, which is much more verbose Go code. I'll likely continue to use mine, but for any future VPS I'll have to give this a try.

Any good guides for this?

Do you have any sources on GitHub moving away from Rails? This is the first that I've heard and my googlefu has returned zero results around this. Just last year they had a blog post around Building GitHub with Ruby and Rails[0] so your remark caught my off guard.

[0] https://github.blog/2023-04-06-building-github-with-ruby-and...

I don't mind this style, it's encouraged by dry-monads with the do-notation. The big concern that I have with this code is it's missing a service level transaction.

Can't you use `mprotect` to allow you to write to memory and execute?

https://github.com/Frodox/execute-machine-code-from-memory/t... has several examples of how to do it.

EDIT: https://www.kvakil.me/posts/2022-10-13-optimizing-mprotect-i... is another good link that explains this.

Not only that, but with https://litestream.io/ things becomes even more interesting.

I'm currently using this for a small application to easily backup databases in docker containers.

ViewComponent, from Github makes writing views much better, but it's far from perfect.

This works pretty good, but we've ran into issues where the downloaded file isn't code signed and then this becomes a big issue. AFAIK, if this is a public CLI then homebrew will codesign for you, if you are distributing a private CLI then you need to solve the code signing issue yourself. Not many blog posts on how to handle this...

+1 for backstage.io. This is something that I hoped the backstage graph would evolve into...

Those built-ins that you are talking about are not as well rounded as a dedicated framework. These built-ins operate at a different operating model than running additional background servers. This typically means that everyone in the org needs to be an Elixir/Erlang expert instead of having experts in Redis, cloud native, ... For better or worse, this is likely a large obstacle for many orgs.

The argument for using Elixir/Erlang is also more difficult when you have large companies like Github and Shopify demonstrating that Ruby can scale.

EDIT:

Let's not forget that it's mostly the DB that slows CRUD apps down. Not the language or the framework.

It'd be interesting if Mozilla offered a iCloud-like solution. Obviously, they wouldn't have the tight integration compared to Apple on mobile or desktop. They'd also need a really compelling use case that Apple can't offer.

What I miss most about LAN parties was the fun of getting all the computers setup. Setting up servers to host things for others to downloads, troubleshooting networking, random projects, ...

That void is somewhat filled with DN42.

... and this is how OCLC was created?

Agreed, I'd also like to know the high-level details of the stack.

I haven't read it yet, but I've skimmed over a couple parts, but I think System-Design Interview insiders Second Edition is a modern book around lots of concepts talked about on HN over the last 5-10 years.

Others on my list that I think are good books:

* Empowered

* Soft Skills

* Pragmatic Programmer

* Clean Architecture

* Staff Engineer by Will Larson

I noticed the UI just filters the data queried. Is this a WIP or will the search feature actually update the search query?

I think fly.io does something like this as well?

You did a good job summarizing the frontend framework evolution, but I'm curious where you think the evolution in backend frameworks are going? I was thinking LiveView, but I also think WASM could come into play as well.

I'm an Eng for a startup using Rails, MySQL, ... Next.js.

The only problems we've had is slow performance of Docker for us with our databases. So much so, we've moved those out of Docker and back to the native. Performance is easily 6x faster. MySQL was also a headache because finding a MySQL 5.7 official Docker container didn't exist for ARM so we needed to use the slow emulation through qemu.

We also have a CLI dev tool that is written in Python and distributed in Docker (x86) which has also been slow. Not enough time to build ARM based Docker image.

Not a large systems, but we started using https://backstage.io to help visualize our software. Additionally, we're hoping to leverage backstage plugins to provide tooling around ownership for our components.

I'm looking forward to more XDP + eBFP, VPP, or FD.io based firewall and routing solutions as I think those are where we'll see the next big improvement in networking at. I'm hoping to get my hands on some NICs that support XDP offloading. I can see the future homelabbers leveraging SmartNICs and/or DPUs for routing/firewall applications instead of using large big iron custom ASIC switches.

Every org is different and I like to point out this article [1] to illustrate it. SRE is really what your company wants it to be. If you have full-cycle devs, then you're likely doing more platform work. If your devs lack the deploy and operate part of the cycle, then that's likely where the SREs will pickup the rest.

[1] https://netflixtechblog.com/full-cycle-developers-at-netflix...

https://github.com/rogchap/v8go is a Go library which makes this easy to accomplish.