HN user

dig1

1,901 karma
Posts3
Comments409
View on HN

The irony is that this may be a $0 revenue user for Grafana Labs.

Why is that ironic? Since Mimir is open-source, $0 revenue users are expected. AFAIK, Grafana Labs relies heavily on go, typescript, and linux, without necessarily being their top financial contributor. They could have kept Mimir proprietary like Splunk, but whether that would have attracted the same level of adoption or community contribution is another matter.

I like to think there is no curve only fashion.

Exactly! For instance, we had pull-based monitoring 20 years ago (Zabbix et al), but we abandoned it because it scaled poorly, favoring push-based agents (for InfluxDB, KairosDB etc). Now Prometheus is all the rage, yet we’re hitting the exact same scaling walls these systems had before. In a few years, we’ll rediscover push agents and call them the best thing since sliced bread.

Ask a twenty-two-year-old to connect to a remote server via SSH. Ask them to explain what DNS is at a conceptual level.

Modern IT has become a ubiquitous commodity, much like the car. You don't need to know how an engine works to drive; while that knowledge might make you more efficient, it isn't strictly necessary to get from A to B. Besides, most twenty-two-year-olds ten years ago didn't know how to use ssh, either.

However, if you want to call yourself an engineer (and work in the field), you must understand the underlying mechanics. IMHO if you want to defeat a competitor today, you don’t need industrial espionage - you just have to cut their internet and/or AI subscriptions. Modern vibe engineers would struggle to function.

The man page is dead for most users. The RFC is unread by most developers who depend on the protocols it describes.

Well, those who are accustomed to using man pages still use them today. I find them far more accurate than whatever an AI might spit out at any given moment. As for RFCs, they were always read by a small population - either those implementing the protocols or the few of us who like to brag about obscure technical details.

You can now write complete programs without understanding what a single line of them does... until something goes wrong in production at two in the morning and you are completely without tools to respond.

I’m not worried about this. When things go south, there will still be experts who will know how to fix them. But since those experts will be fewer and farther between, they will likely charge $1k/hr, and rightfully so. If you are in that field, more power to you! :D

Or like:

"I’m not a mechanical engineer, but I watched a five-minute YouTube video on how a diesel engine works, so I can tell you that mechanical engineering is a solved problem."

it assumes companies that are replacing labor with LLMs are willing to pay as much as (or at least a significant fraction of) the labor costs they are replacing.

And it’s worth reiterating that most (all) of these LLM/AI providers are currently operating at significant losses. If they aim to become even modestly profitable, prices will have to increase substantially.

True. But the US want to remain the country everyone relies on if it wants to preserve the dollar as the world's primary trade, reserve and settlement currency.

Dollar dominance gives the US disproportionate leverage over global finance and allows it to shape the rules of the system. Absent this asymmetry, it is difficult to imagine US tariffs or financial pressure (or any kind of pressure) would carry comparable global impact.

1 GB of RAM for Postgres is really only useful for tinkering IMHO. Even for development, you’ll quickly need more memory, so HA doesn’t provide much value here. If you go with something even remotely reasonable (4 GB RAM, 200 GB SSD, 1/2 vCPU — and that’s still on the low end), the cost jumps to about $290/month. For that price, you could easily hire someone to set up HA Postgres for you on Hetzner or OVH and once configured, HA Postgres typically requires minimal ongoing maintenance.

Also, this is a shared server, not a truly dedicated one like you’d get with bare-metal providers. So, calling it "Metal" might be misleading marketing trick, but if you want someone to always blame and don’t mind overpaying for that comfort, then the managed option might be the right thing.

Why Startups Die 7 months ago

A start-up needs to have an exit to pay back investors

It depends on the kind of investors you want to attract for your startup. Some investors are interested in building a slow-growth, long-term, stable company, while others prefer a higher-risk approach and will expect fast results. IMHO choosing the right kind of capital is just as important as focusing on the product.

And don’t hesitate to use a JRE (Java Runtime Environment) if all you need is to run java/jvm applications - assuming the application doesn’t already ship with its own runtime. A JDK is roughly 140 MB, while a JRE is about 60 MB (and can be further minimized). I’ve seen installations of the full OpenJDK just to run apps, which is unnecessary in most cases.

HN uses Cloudflare

From the ping output, I can see HN is using m5hosting.com. This is why HN was up yesterday, even though everything on CF was down.

Writing high-throughput web applications is easier than ever. Hosting them on the open web is harder than ever.

Writing proper high-throughput applications was never easy and will never be. It is a little bit easier because we have highly optimized tools like nginx or nodejs so we can offset critical parts. And hosting is "harder than ever" if you complicate the matter, which is a quite common pattern these days. I saw people running monstrosities to serve some html & js in the name of redundancy. You'd be surprised how much a single bare-metal (hell, even a proper VM from DigitalOcean or Vultr) can handle.

Blender 5.0 8 months ago

it is perhaps the only open source software that managed to beat all the commercial software in its niche.

gcc? It’s hard to imagine any of the projects mentioned without a good compiler.

...does it all add up to cost savings?

IMHO it adds, but only if you are big enough. Netflix level. At that level, you go and dine with Bezos and negotiate a massive discount. For anyone else, I’d genuinely love to see the numbers that prove otherwise.

There's zero personal responsibility

Unfortunately, this seems to be the unspoken mantra of modern IT management. Nobody wants to be directly accountable for anything, yet everyone wants to have their fingerprints on everything. A paradox of collaboration without ownership.

a16z is heavily long on AI, so this article sounds very biased.

From the article: If you live in the United States today, and you accidentally knock a hole in your wall, it’s probably cheaper to buy a flatscreen TV and stick it in front of the hole, compared to hiring a handyman to fix your drywall.

Probably because the US has been focused on services for years rather than physical goods production. Everything else in US is focused on importing cheap(er) goods or materials.

On the other hand, I think he wants to push the narrative that AI is seeing enormous productivity gains.

That is my impression as well. I would be thrilled to see this mythical 10x productivity. Even with 2x productivity, I would be highly pleased. This should mean developers (and everyone else) are producing 2x more quality, software (and general services) are 2x better? I see none of that, except 2x more junk. Did AWS, GCP, or anything else become 2x cheaper and 2x more stable? Maybe I'm living under a rock.

The general setup for the largest players in that space was haproxy in front of nginx in front of several PHP servers in front of a MySQL database that had one primary r/w with one read only replica.

You'd be surprised that the most stable setups today are run this way. The problem is that this way it's hard to attract investors; they'll assume you are running on old or outdated tech. Everything should be serverless, agentic and, at least on paper, hyperscalable, because that sells further.

Today at AWS, it is easily possible for people to spend a multiple of the cost of that hardware setup every month for far less compute power and storage.

That is actually the goal of hyperscalers: they are charging you premium for way inferior results. Also, the article stated a very cold truth: "every engineer wants a fashionable CV that will help her get the next job" and you won't definitely get a job if you said: "I moved everything from AWS and put it behind haproxy on one bare-metal box for $100/mo infra bill".

In Defense of C++ 10 months ago

You have to learn about what the insane move semantics are (and the syntax for move ctors/operators) to do fairly basic things with the language

That is simply not true. You can write a lot of C++ code without even touching move stuff. Hell, we've been fine without move semantics for the last 30 years :P

Overloaded operators like operator*() and operator<<() are widely used in the standard library so you're forced to understand what craziness they're doing under the hood

Partially true. operator*() is used through the standard library a lot, because it nicely wraps pointer semantics. Still, you don't have to know about implementation details, as they depend on how the standard library implements the underlying containers.

AFAIK operator<<() is mainly (ab)used by streams. And you can freely skip that part; many C++ developers find them unnecessarily slow and complex.

Basic standard library datatypes like std::vector use templates, so you're debugging template instantiation issues whether you write your own templated code or not.

As long as you keep things simple, errors are going to be simple. The problem with "modern C++" is that people overuse these new features without fully comprehending their pros and cons, simply because they look cool.

Contributors and maintainers often have less power than even the smaller companies, and users have less power yet.

If contributors/maintainers are not happy with what the small company does, they can fork the project (assuming a liberal license) and continue in their own way. Valkey is a good example (with an interesting twist of license dynamics where Redis can use Valkey code now, but not the other way around).

We have built a world where it is often easiest to just use whatever a cloud provider offers

And, IMHO, this is the major problem in the dev community these days - we've become lazy and focused on nonsense ("pretty"/unusable UIs, web gymnastics, llm, "productivity" etc.). We didn't have problems in the past to fork or reimplement OSes (various BSD instances), compilers (gcc versions), databases (MariaDB), and so on. There are tons of geniuses around hacking on cool stuff, but, sadly, the loudness of various hipsters and evangelists limits their visibility.

Those providers may not contribute back to the projects they turn into services, though, upsetting the smaller companies that are,

The significant contribution that these providers (AWS, et al.) make to these projects is often overlooked - free advertisement. If I can remember correctly, ElasticSearch got popular when AWS started to offer it as a service. Additionally, cloud providers usually contribute (by employing core developers, shipping patches or testing) to the kernel, gcc or jdk, from which these small companies benefit significantly. In contrast, they themselves could do none of this.

But it is easier to blame "big scary clouds" than to rethink your business model. Be honest, start closed; no one will touch that and no one will be standing in your way.

Well, Bitnami didn't produce own hardware stack either ;) Joke aside, it's not naive - CentOS, Alma, Rocky, Ubuntu... FOSS community has some experience with these things

Facebook/Meta/Zuckerberg seem almost uniquely unable to turn the startups into great new businesses, when compared with the other big tech companies.

Really? Instagram, WhatsApp... the two most used apps & services in the world?

Google added Chrome, Android, cloud, Youtube,

It's arguable how GCP is profitable, but chrome/android/yt are money-losing businesses if you exclude ad revenues.