I initially reached for Docker actually, but when I started researching how to run it securely, I just thought "I don't need this. Systemd is already there and does all of this in an easier and more direct way".
I moved all my stuff from AWS to a Hetzner VPS recently. I don't have much, and AWS was actually cheaper, but I'm so much happier having everything in one, simple spot.
There's a gap in my knowledge so far, which I think is mirrored in this post: I have been piecing together my server by hand, and I _know_ I will regret this at some point, but I don't know how I want to solve this yet. I don't want to involve Docker in this setup. Perhaps I should go back to Saltstack or Ansible, or maybe there's something in Nix for me, or snap/flatpack maybe, I don't know. There's a good chance I'll just never solve it, but it seems like there's a gap there that's waiting for a great, simple, small solution (or it exists and I just don't know about it).
So after all these years (decades now) of learning and working in linux every, single, day, I still have a lot to learn! :D
We believe that apps should never crash. They should be free of bugs. They should be fast — they should feel lighter-than-air.
We believe that quality is more important than just piling on features; we believe that quality is the most important feature. And we believe that high quality is transformative — it makes for an app you never hesitate to reach for. You can rely on it, and you do, again and again.
This makes us slow to add features. We are adding features — but never at the expense of how it feels. Never at the expense of reliability and speed.
A lot of tech debt I've seen stems from people tacking things onto a loose foundation – adding API endpoints when there's no clear pattern, adding validation or defaults in different ways, organizing layers of code in various ways, multiple implementations of the same business need.
This is compounded when people come and go. The software/tech industry, in my experience, does not encourage long tenure – layoffs, reorgs, and the general trend of people hopping between employers every 2-3 years.
Startups also love the idea of building things fast and ugly, and 5 years later that leaves the company with a successful product (hopefully), a team that's grown fast (and turned over multiple times), and a shaky foundation.
Engineering generally seems open to paying down tech debt, but there's an overwhelming amount of it sometimes, and someone needs to deeply understand the problem and lay out a clear plan for taking care of it, and that takes serious effort.
I haven't written about it much yet, but atlas9.dev has an infrastructure component to it. I actually spent most of today researching and experimenting with infrastructure and I plan to write about it soon.
atlas9 is about setting up a foundation/framework for building and deploying apps that takes care of more of the common issues. Infrastructure (build, deploy, monitor, config, secrets, etc etc) is a big part of that. I've been focused on the application code lately, but I suspect infrastructure is where the meat of the problem lies.
I can relate to that. I have a ton of bookmarks and open tabs that I've been meaning to read for weeks or months now. I guess that's why I'm hoping a daily reading list might give me a bite-sized chunk to work through.
In my experience, archived objects are almost never accessed, and if they are, it's within a few hours or days of deletion, which leaves a fairly small chance that schema changes will have a significant impact on restoring any archived object. If you pair that with "best-effort" tooling that restores objects by calling standard "create" APIs, perhaps it's fairly safe to _not_ deal with schema changes.
Of course, as always, it depends on the system and how the archive is used. That's just my experience. I can imagine that if there are more tools or features built around the archive, the situation might be different.
I think maintaining schema changes and migrations on archived objects can be tricky in its own ways, even kept in the live tables with an 'archived_at' column, especially when objects span multiple tables with relationships. I've worked on migrations where really old archived objects just didn't make sense anymore in the new data model, and figuring out a safe migration became a difficult, error-prone project.
https://helmtk.dev is a toolkit for helm chart maintainers, including a structured template language than can compile into helm templates, and a test suite tool for writing tests in javascript. Super handy I think.
https://blog.atlas9.design is about building a better software experience by solving more of the common stuff from the start: IAM, builds, API design, etc. I'm currently designing and building a Go-based framework to start.
I'm curious how it will be sustainable. There's a credit system, they're not very clear about how it works. Apparently it earns you gift cards or something?
My coworkers and I spent the last couple years struggling with helm chart dev. I was always curious whether there was a better way. This blog post is about that journey and the tool I created to try to make this better for everyone. Enjoy!
I share a lot of this sentiment, although I struggle more with the setup and maintenance than the diagnosis.
It's baffling to me that it can still take _so_much_work_ to set up a good baseline of observability (not to mention the time we spend on tweaking alerting). I recently spent an inordinate amount of time trying to make sense of our telemetry setup and fill in the gaps. It took weeks. We had data in many systems, many different instrumentation frameworks (all stepping on each other), noisy alerts, etc.
Part of my problem is that the ecosystem is big. There's too much to learn:
OpenTelemetry, OpenTracing, Zipkin, Micrometer, eBPF, auto-instrumentation, OTel SDK vs Datadog Agent, and on and on. I don't know, maybe I'm biased by the JVM-heavy systems I've been working in.
I worked for New Relic for years, and even in an observability company, it was still a lot of work to maintain, and even then traces were not heavily used.
I can definitely imagine having Claude debug an issue faster than I can type and click around dashboards and query UIs. That sounds fun.
I’ve used Torx in a dozen projects over the last year, because that’s what everyone sells now. I’ve hated every minute of using them. The screw heads strip so easily, even on expensive stainless steel versions.
I'd love to know more about this line: "There’s also a little flag in the DCS byte that tells the phone whether to self-destruct the message after sending it"
And also, how do towers deconvolute all those signals?
I've been learning (mostly 2D) graphics as my side project for a couple years now. I spend a ton of time on this project. I still feel like a beginner. It is one of the more complex topics I've ever delved into.
I've crawled through more topics than I can list here. Many of them were not easy to learn, due to disorganized learning resources and materials.
Documentation and information is scattered, frequently outdated, sometimes sparse, and just downright messy. OpenGL and its many quirks and legacy versions muddy the waters too. I've considered trying to pull this into one big guide, hopefully resulting in something like the Filament docs [1].
Side note: macOS (my dev env) is a terrible place to write OpenGL, I've learned. Debugging tools are practically non-existent.
Also: top-left logos should link to the root (syncthing.net) not to a sub-root (forums.syncthing.net). When I land on your forum site and I want to know what syncthing is, I expect to find the answer by clicking the top-left logo in the header.