khazit

It's because for providers the bottleneck isn't capacity (which is dirt cheap) but IOPS and bandwidth. To keep transfers fast they need to spread data across a lot of physical disks, meaning they often times sit mostly empty. Egress fees are a way to monetize that empty storage and make sure there is an incentive to minimize egress traffic.

We use R2 (not affiliated) which doesn't have egress fees.

I was surprised too! The OCI layout for storing images is actually pretty simple. But for some weird reason you can't stream it straight into Docker. docker load only accepts tarballs.

So you need something to wrap the layout into something Docker understands. Because S3 is not a server, you have to construct the tarball on the fly as the image is pulled and stream it straight into docker load.

I still think S3 is underutilized.

The range of things you can do with blob storage and a (very simple) auth model are surprisingly broad.

We recently replaced our Docker container registry with S3 using a tiny tool [1] we built in-house. I think that even with current capabilities, we can still model a lot services as a very thin layer over object storage.

[1]: https://github.com/Simple-Observability/grue

We dismissed using journalctl at the very start. We’ve had similar experiences with other CLI tools: the moment you start embedding them inside a program, you introduce a whole new class of problems. What if journalctl exits? What if it outputs an error? What if it hangs? On top of that, you have to manage the subprocess lifecycle yourself. It’s not as easy as it may seem.

You can also argue that sd_journal (the C API) exists for this exact reason, rather than shelling out to journalctl. These are technical trade-offs, doesn't mean we're fuckups

There is an existing pure Go library [1] written by someone else. The issue is that we weren’t confident we could ship a reliable parser. We even included an excerpt from the systemd documentation, which didn’t exactly reassure us:

> Note that the actual implementation in the systemd codebase is the only ultimately authoritative description of the format, so if this document and the code disagree, the code is right

This required a lot of extra effort and hoop-jumping, but at least it’s on our side rather than something users have to deal with at deploy time.

[1]: https://github.com/Velocidex/go-journalctl

The macOS bit wasn’t about trying to get systemd logs on mac. The issue was that the build itself fails because libsystemd-dev isn’t available. We (naively) expected journal support to be something that we can detect and handle at runtime.

Of course you still need one binary per CPU architecture. But when you rely on a dynamic link, you need to build from the same architecture as the target system. At that point cross-compiling stops being reliable.

In case you don't already know, there are Github-hosted runners that run Windows arm64 [1]

Also, it's not what you're asking, but self-hosted runners are a security nightmare if you don't have the hardware to completely isolate them from your local network.

[1] https://github.com/actions/partner-runner-images/blob/main/i...

That’s not actually a bug (maybe the message need to be more verbose). The agent is running, but it doesn’t yet know what data to collect. You’ll need to finish the setup in the UI by choosing what metrics/logs you want. Once you do that, the error will go away and the agent will start collecting data

I’m still working on Simple Observability:

https://simpleobservability.com

I built it because I needed two things:

- A super easy-to-install monitoring tool that doesn’t require bash scripts or config files

- A mobile-friendly, UX-first interface where I can check everything from my phone

It’s now pretty feature complete. I can see a full picture of all the servers and VPS I run straight from my phone.

Setup is one command, no config files, and everything else happens in the UI. There’s a catalog of predefined alert rules, and creating new ones is easier than anything else I’ve used.

There’s a free tier if anyone wants to try it!

Thanks for the feedback. I'll make sure to add screenshots.

For the alerts it is configurable pretty quickly (you just select what you want to monitor, a threshold value, and a notification channel). But I’ll look into having some sensible defaults built in so it works out of the box

I'm working on Simple Observability[0], a platform for monitoring servers (metrics and logs). Think of it as a super simple alternative to the Prometheus + Grafana + Loki stack, designed for teams who just want to know “is my server healthy?” without setting up and maintaining a full observability pipeline.

It uses a lightweight, open-source agent[1] that collects data and pushes it to the backend, so it works behind firewalls and doesn’t require any open ports or scraping setup. The goal is to get useful monitoring and alerting with minimal effort: one command install and a UI-based configuration.

[0] https://simpleobservability.com

[1] https://github.com/Simple-Observability/simob-agent

From the 10-Q filing: "We are focused on the continued development of Intel 14A, the next generation node beyond Intel 18A and Intel 18A-P, and on securing a significant external customer for such node. However, if we are unable to secure a significant external customer and meet important customer milestones for Intel 14A, we face the prospect that it will not be economical to develop and manufacture Intel 14A and successor leading-edge nodes on a go-forward basis. In such event, we may pause or discontinue our pursuit of Intel 14A and successor nodes and various of our manufacturing expansion projects"