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.
I am complaining about the language (phrasing) used: a Python, TypeScript or Java program might be truly portable across architectures too.
Since architectures are only brought up in relation to dynamic libraries, it implied it is otherwise as portable as above languages.
With that out of the way, it seems like a small thing for the Go build system if it's already doing cross compilation (and thus has understanding of foreign architectures and executable formats). I am guessing it just hasn't been done and is not a big lift, so perhaps look into it yourself?
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.
- 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.
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
Ah thats what I get for not readin! It's working perfectly! The only thing missing for me is ingesting the logs for my service directly from journalctl, that would be amazing
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.
For the landing page, I think it'd be useful to see an actual screenshot of the UI. Also, what I'm looking for in a solution like this is to receive this information passively — I don't want to need to proactively watch a dashboard. I would want to receive email alerts when, for example, I'm running out of disk space. It says on your landing page that you provide this feature, but it also says it's configurable. Everything on Grafana is configurable, but tbh it's a PITA to configure. It'd be nice if SO just worked OOTB wrt alerts.
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
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"
reply