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.
From the opposite side of things, I feel the same about OPFS. Finally having something that performant that multiple workers can operate against in a browser is such a massive boon. You could plug something like that in to it locally with markedly less bullshit than you would have had to do previously with the other APIs.
That sounds really cool — I tend to agree with you that S3 and similar are underutilized, but I remember that essentially all of the providers charge for bandwidth measured in gigabytes and I'm like no. My consumer line is measured in megabits per second and if I have to pay for my data usage the way it's paid for in data centers it would be far more expensive. Somehow consumer ISPs, who have to pay for the lines, are cheaper than than the cloud providers.
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 remember that essentially all of the providers charge for bandwidth measured in gigabytes" - sure, but the cost per GB is shockingly cheap. If you're doing things well, you can do a lot inside those pricing structures.
Alternatively you can stand up your own object store services, but that's not something I would like to do.
Huh? We're talking about the same S3 right? At list pricing, 1TB is $23/TB to store for one month, and about $90/TB (plus request fees) to send it out to the internet.
While hard drive prices are roughly 3x what they were a year ago, the price per TB of a new hard disk averages around $30/TB -- assume 2x overhead for other hardware and extra space for parity etc, a disk pays for itself in less than 3 months and lasts 5 years or more.
If you assume it takes 1 month to download that 1TB (about 3Mb/s) that's $29.16/Mbps. When I first started buying internet transit in Europe back in 2008 I think I was paying under $10/month. It's now under $0.10/Mbps pretty much anywhere in the US or Europe at the big datacenters.
None of the "big" object storage services are cheap. They're somewhat reasonable if you only access the data from within the same region, but absolutely insane if you ever want to ship that data outside of that cloud vendor (or to another region etc). The pricing of storage and egress has not changed in a decade (I believe AWS last lowered the price of either in 2016) and in fact it costs even more now due to things like NAT Gateways etc.
It's definitely not "shockingly cheap". It's just cheaper than $80/TB of gp3 or $45/TB of st1, and while sc1 is $15/TB it has a baseline performance of only 12 MB/s. There's quite a few companies out there that have $6/TB/month object storage plans with similar performance, rising to about $15-$18/TB/month for SSD backed storage with far lower latency figures.
AWS have found the ideal captive market: computer engineers who don't know how computers work or how much they should cost.
Whatever AWS is selling you - except Deep Archive - I'll figure out a way to sell you for half that price, if you want, and it'll still be 80% profit for me. Your only downside will be that I don't know what I'm doing so it might not be reliable - but neither is AWS.
Not just AWS. IIRC, GCS and ABS are slightly cheaper for storage but more for egress. To be fair to them, their reliability is pretty much second-to-none, whereas many of those at the very cheap end pretty much just ran a Ceph/RADOS cluster and then wondered why they were having lots of problems with reliability -- but with things like RustFS becoming more and more popular, the object storage racket is long overdue a shake-up!
We run Ceph at work. Reliability problems have been exclusively caused by us penny-pinching and trying to have as few drives and servers as possible, causing latency issues. If we had a nice margin instead, I can't see there would be any problems.
Not really. 1TB is 90 USD, so if you are doing anything with video that is gone pretty quickly. Same with software distribution - your 200mb download hits that with 5000 downloads. Convert a 10 usd trial at 1 percent and almost 20% is eaten in bandwidth charges.
At those prices, it only makes sense to use it for data that never leaves that providers cloud (which I assume, but cannot prove, is their intention).
> My consumer line is measured in megabits per second and if I have to pay for my data usage the way it's paid for in data centers it would be far more expensive
Well because your provider assumes you are not using all your bandwidth constantly. Cloud bandwidth is only billed for you actually use
It's still true that "clouds" cost much more than proper internet connections at DCs. E.g. AWS wants you to pay $90/TB, Hetzner $1.50/TB, a good deal on a contract is probably half what Hetzner pays since they need profit too.
And if you have two specific endpoints you need to transfer data between at a high rate, you can get stupidly cheap cost per GB on a leased line in exchange for making all that commitment upfront.
I'm a little surprised the Docker CLI doesn't support this directly, since gcr.io works this way. Maybe there's a thin layer between the bucket and the CLI? Neat that you worked it out for the generic case.
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 worked on OCI for quite a while, the very short and cynical answer is that Docker thought the registry was their moat for a long time and fought tooth and nail to keep it at the detriment of almost everything else. (The longer version is a bit more diplomatic.)
Even better, the OCI distribution protocol (which was Docker distribution until a few years ago) is not a static-blob-over-HTTP protocol! The blob bits are and you can route them to blob storage but you need a smart server for a few key bits of the protocol.
Back in the day I made proposals for distribution formats that didn't have these flaws and were more distributed (and previous proposals like AppC's discovery had similar ideas) but they were roundly rejected by the Docker people.
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
> If you need access to the raw journal data in serialized stream form without C API our recommendation is to make use of the Journal Export Format, which you can get via journalctl -o export or via systemd-journal-gatewayd.
Certainly sounds like running journalctl, or using the gateway, is a supported option.
Does Go really not have any libraries capable of supervising an external program? If you'd considered journalctl, why didn't you mention it in the article? As many have pointed out here, it is the obvious and intended way to do this, and the path you chose was harder for reasons that seemed to surprise you but were entirely foreseeable.
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.
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.
Well... yeah. It's a Linux API for a Linux feature only available on Linux systems. If you use a platform-specific API on a multiplatform project, the portability work falls on you. Do you expect to be able to run your Swift UI on Windows? Same thing!
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?
they're only portable if you don't count the architecture specific runtime that you need to somehow obtain...
go doesn't require dynamic linking for C, if you can figure out the right C compiler flags you can cross compile statically linked go+c binaries as well.
It's a tooling issue. No one has done the work to make things work as smoothly as they could.
Traditionally, cross-compilers generally didn't even work the way that the Zig and Go toolchains approach it—achieving cross-compilation could be expected to be a much more trying process. The Zig folks and the Go folks broke with tradition by choosing to architect their compilers more sensibly for the 21st century, but the effects of the older convention remains.
In my experience, the cross-compiler will refuse to link against shared libraries that "don't exist", which they usually don't in a cross compiler setup (e.g. cross compiling an aarch64 application that uses SDL on a ppc64le host with ppc64le SDL libraries)
The usual workaround, I think, is to use dlopen/dlsym from within the program. This is how the Nim language handles libraries in the general case: at compile time, C imports are converted into a block of dlopen/dl* calls, with compiler options for indicating some (or all) libraries should be passed to the linker instead, either for static or dynamic linking.
Alternatively I think you could "trick" the linker with a stub library just containing the symbol names it wants, but never tried that.
You just need a compiler & linker that understand the target + image format, and a sysroot for the target. I've cross compiled from Linux x86 clang/lld to macOS arm64, all it took was the target SDK & a couple of env vars.
Clang knows C, lld knows macho, and the SDK knows the target libraries.
Well, you need to link against them and you can't do that when they don't exist. I don't understand the purpose of a stub library, it is also only a file and if you need to provide that, you can also provide the real thing right away.
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"
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