ragall
ragall on Hacker News
That's a rather stupid reply. The economics of the production have changed, but not the incentives.
Your case I point is irrelevant. This was a hypothetical scenario, something you seem unable to comprehend.
> The agentic age is, I hope, going to question a lot of old assumptions & needs about what we want to run.
There's no reason to think that "the agentic age" will bring about any runtime efficiency. It may, perhaps, reduce development time but it doesn't introduce any new incentive to make software more efficient. It may happen, in a very roundabout way, by making consumer RAM massively more expensive which might induce customers to choose more efficient software, but it's too early to tell if this effect if happening.
> I can't really fault people for using it.
We can and we should.
Your point is wrong. An automated incident investigation tool needs "all kinds of information".
You forgot that this whole discussion started from the question "What contexts would the AI model need for analyzing, let's say, cluster-wide incident other than the observability data that such systems anyway collect already?". If one wants to automate resolution, then it becomes necessary to feed all kinds of information into the decision engine, precisely to compensate the incompleteness of each source of information.
They're still being solved because there are people that hold that information in their minds. If you want to automate this, you need to feed the source code in its entirety into the decision engine.
Very often the causes of an incident aren't visible in metrics because the relevant metrics aren't collected. Sometimes an incident is caused by external actors, etc...
Of course it's misunderstood and misused, but that doesn't mean that more discerning people can't understand where it came from and why, and then used the term properly.
The entire company code base, design docs, realtime threat intelligence feeds, all the vendors' status pages, etc...
No, what you descrive is SRE. DevOps was the idea to give people that work 100% as developers the ability to do some amount of ops work (let say 5%), as a way to break the silo between Dev and Ops that existed in older organizations.
No, everyone in Italy got to speak to people that lived through those times.
Due to automation, the used market has gotten more efficient so places like Goodwill are no longer a good deal because they're selling their high value items (like good electronics or 4K Blu-ray discs) to various intermediaries.
For the same reason why I try to avoid work done by slaves, for example Chinese solar panels manufactured in Xinjiang concentration camps. They're repugnant at origin.
> it seems odd to care how 10% of it was produced
To me, it seems odd not to care.
Go buy an AVR and get yourself a proper 5.1.2 home theater (even in a living room); and then the TV will be just a dumb display with the AVR acting as multiplexer.
In any distributed system beyond toy size, forcing an update is not possible.
> infrastructure code for GCP that interrogated hardware availability
How do you to do that ?
> if you're so inclined you can probably point a clanker at it
I'm not. Too bad there's nothing meant for humans.
The developer's reply was very reasonable and measured. The user, on the other hand, was very rude.
> These were both solved as part of the data model via globalrevs and obliteration respectively
Is there some paper or other technical publication regarding these concepts ?
I'm not convinced that Merkle DAGs are useful or worth the bother. Piper's system of linear indices has a few nice properties:
1) when a defect is identified in a library, the extent of the defect becomes an interval [CL that introduced it, CL that removed it] and it makes it trivial to test whether a compiled artifact is affected by that defect; more generally the UX is a lot better
and 2) it makes whole-repository rewrites trivial, so that existing commit sequence IDs are preserved while retroactively removing sensitive files that shouldn't have been added to the repo. Git and Mercurial make such rewrite a huge pain in the arse, while this is an essential feature to have in an enterprise VCS.
Right. It stinks, but I can hold my nose for a whole while I make money. Pecunia non olet.
> The beauty is the elegance of the solution,the optimisation,the way it works. All of these things are problems worth solving.
Yes, but LLMs, and especially their mandatory and exclusive use, make that impossible.
> This might be your favourite thing - but it's not the only thing you can solve? What about the second favourite thing?
There is no second favorite thing.
> There are always opportunities to explore an alternative - in a different area, in a different country. Many options to consider before concluding there are none.
I'm already in country number 9 since leaving Italy. We'll see.
> You are not just a SWE/whatever your job is - you are a problem solver
You should know by now that many of us joined the profession because we like programming and not "problem solving". In 23 years of career I've never cared much about any business problem of the companies I was working for. I never cared about solving customers' problems, or the "impact" of my work, only about the technical beauty of it.
> Building a write-ahead log-style Merkle DAG was very far away from what anyone else was doing in 2018
That completely ignores the fact that Google's Piper had something very similar working already in 2012.