buchanae

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

I love the philosophy page: https://netnewswire.com/philosophy.html

"""

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.

I'm interested, tell me more. What about Oxide attracts a homelab user?

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.

Hm, leveraging CloudKit is smart. I am fully assimilated into the Apple world.

I'm a little wary of something watching my clipboard, honestly. A lot of passwords and sensitive information goes through there.

Drag-and-drop into a menu bar icon is super clever though.

Well done. It might be a little more than I need, but I'm cheering you on nonetheless.

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.

Ah, that's an interesting idea! I had never considered using partitions. I might write a followup post with these new ideas.

I'm working on two projects:

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.

One of the best articles I've read in awhile.

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?

Mine too. Safari on iOS. I couldn’t click back to HN

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.

[1] https://google.github.io/filament/Filament.md.html

Agreed.

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.

But, https://play.golang.org/p/naE55o3_xFP

I guess the first link is converting the float constants to ints at compile-time?

(edit: oh, it's actually mentioned in the article. I should read more carefully)

Thanks for taking the time to explain the details.

If we were to start with a clean slate, could we come up with something natural while still having a clean design with respect to commands? Would it be worth it?

The fact that those details haven't sunk in after more than a decade points to an opportunity for a better design, I think. For example, I can pick up Go, Java, Perl, PHP, JS, Nim, etc and memorize the if-statement details in about 5 minutes. Whether or not anyone would use such a shell, I don't know.

After 15 years, I still struggle to test if a string is empty in shell languages. Do I use square brackets, double square brackets, equal sign, double equal sign, test -n, set -q, wtf mate? Do I need to wrap my string variable in double quotes? single quotes?

Fish looks great, and I'm going to give it a try, but I ran into these same old shell scripting issues within 2 minutes of trying to configure my prompt, which is a bummer. Took me 10 minutes (I'm ashamed to say) to end up at `if test -n "$git_branch"` (double quotes are critical).

I'll be excited when someone invents a shell that feels natural in this respect. Perhaps the nature of shells and commands makes this impossible? Or are we just stuck in a box?

I just implemented an IMAP parser/server in Go. I found myself thinking (wishing) a lot for HTTP, JSON, stateless connections, etc. I'm happy to see someone has taken the lead in improving such an entrenched technology.

Love the work you're doing on observablehq mbostock! I am really impressed with the volume and variety of content you create. Especially love the generative art stuff!

Cool! Took me a couple minutes to figure out that I click the mouse to swing the sword. Before that, I had tried just about every keyboard button. Only while going to click "quit" did I realize that the mouse swings the sword.

Playing the WebGL version on a macbook air, in Firefox, by the way.

Essentially, you can write CLI code using functions and struct types following a certain convention, and then use these tools to generate code for flags, env vars, config files, subcommands, etc.

  func AddTask(opt Opt, path string)

...will be turned into a CLI command "add task" where all the fields of "Opt" can be set via flags/env/yaml, and the positional args are mapped in too. Default values are taken from "DefaultOpt()", if it exists.

I've written a number of Go apps now, and I always feel like CLI + config is a struggle. This is my latest attempt to distill all that experience into something I can reuse. It's still rough around the edges, but the armature is there now. Hopefully you can get a feel for what it is and where it's headed. There's still a long list of additions and cleanups I want to make.

Thanks in advance for any feedback!

I'm an American who was lived and worked in New Zealand in Australia. I couldn't believe how easy it was to do taxes there, there was basically nothing to do.

I wonder if there's a limit to thread depth.

I don't know about any video, but I have met Tibetan refugees in northern India and heard their stories about escaping via the Himalayan mountains, and the need to carefully avoid Chinese guards. The stories were haunting. Traversing the Himalayas is no joke.