schmichael

> feeling entitled to continue living in a place

Are you suggesting people are not entitled to live on land they own and should be forced to relocate? Since you've made their land worthless, how are they paying for this new place to live?

I heard a water district manager for a southwestern US city once say: "it's easier to move water than people." What if we adapted your statement for what the law actually allows?

> A whole lot of it is water being in stupid places feeling entitled to continue being in a place without the people nearby to drink it.

This implies we should move water to where people need it which is both legal and reflects reality even if it sounds very silly. Physics is even on our side here: water is deposited as snow on mountains where there are few people. It flows downward under the force of gravity to where people actually live. It's a pretty nice natural system to take advantage of!

The details here matter a lot: should we socialize the costs of moving water among people who do not directly need that water? Should people in Seattle pay for people in Yakima to get water? Irrigating dry unpopulated areas is a great way to produce food that is uneconomical to produce in or near cities!

Water management is a complex problem since it's needed for sustaining not just people, but the food people eat. There's no easy switch to flip here and just solve the thing.

Absolutely nothing beats the integration of Apple software and hardware. As it should be because they don't give you another option! You can't run Apple software on anything else (without hacks), and you can't run anything else on Apple hardware (without significant effort and sacrifice in functionality). This is Apple's whole design philosophy and value prop, and they are essentially unbeatable at systems integration.

This deep software/hardware integration means Apple absolutely destroys everyone at battery life. No contest. If you want to optimize for battery life, Apple is the choice.

The deep integration also makes Apple's security quite good. Obnoxiously so as they make even common operations like downloading software off the web take extra steps.

That being said as soon as you stray outside of a pure Apple ecosystem, Linux wins in my experience. Plugging a Logitech mouse into my MacBook prompted me to install Logitech keyboard drivers... Not only was the device type wrong but drivers?! ...for a simple input device?! I haven't had to worry about printer, mouse, keyboard, webcam, usb mic, drawing pad, etc drivers in years. Simple devices almost universally Just Work in Linux without having to install or configure anything. It's mind boggling when I touch Windows or macOS and am greeted with proprietary drivers for something like a basic laser printer.

But there's plenty of counter-examples: Nvidia requires their proprietary driver to fully utilize their hardware, but the driver is much better than it used to be. My understanding is that no one on Windows really enjoys dealing with Nvidia drivers either, so it's probably a similar scenario.

At the end of the day I use both Linux and macOS regularly and prefer Linux overall. My Macbook Air's battery life and lack of fans does make it unbeatable for actual lap-top computing, and when I want to look and sound good on a Zoom call I can always count on its builtin camera and mic. So I basically use my Macbook as a laptop form factor iPhone or iPad, which I think is Apple's intent and fills a niche for sure.

Sometimes when I see my parents or other non-tech people using their phones I'm just aghast at what they put up with. We truly never left the Bonzi Buddy era of the 90s. Simple candy crush clones with banner ads on the top and bottom + interstitial ads every few minutes. Maybe throw in some gambling... ...or visit any given US newspaper or local TV station site without an ad blocker. Fans will spin, scrolling will stutter, and what little content there is will barely be visible through the videos about how chugging olive oil like jesus will give you abs like judas.

The combination of technical prowess and relative wealth of the average HN commenter means I bet we see 1/100th the ads of the average consumer. It's wild out there.

> $20/month product with ads

That's a Netflix + Hulu subscription - with ads in both. Before streaming people regularly paid $50/mo (not adjusted for inflation) for cable TV with ads.

While it's easy to bemoan Google pushing ads into every corner of our digital lives, I think they arguably offered an unprecedented level of services relative to the number of ads, and we all got used to that.

Now whether OpenAI could ever push enough ads to make a profit: I have no idea! It's very interesting to see this race actually start.

Step 1: Google made an excellent search engine where the top result is often the right choice for many common queries.

Step 2: Sell the top result slot.

Step 3: Profit.

> The problem is, once you “injection-proof” your agent, you’ve also made it “useful proof”.

I find people suggesting this over and over in the thread, and I remain unconvinced. I use LLMs and agents, albeit not as widely as many, and carefully manage their privileges. The most adversarial attack would only waste my time and tokens, not anything I couldn't undo.

I didn't realize I was in such a minority position on this honestly! I'm a bit aghast at the security properties people are readily accepting!

You can generate code, commit to git, run tools and tests, search the web, read from databases, write to dev databases and services, etc etc etc all with the greatest threat being DOS... and even that is limited by the resources you make available to the agent to perform it!

I don't think this is accurate.

Readonly access (web searches, db, etc) all seem fine as long as the agent cannot exfiltrate the data as demonstrated in this attack. As I started with: more sophisticated outbound filtering would protect against that.

MCP/tools could be used to the extent you are comfortable with all of the behaviors possible being triggered. For myself, in sandboxes or with readonly access, that means tools can be allowed to run wild. Cleaning up even in the most disastrous of circumstances is not a problem, other than a waste of compute.

Fair, I forget how broadly users are willing to give agents permissions. It seems like common sense to me that users disallow writes outside of sandboxes by agents but obviously I am not the norm.

I'm unconvinced we're as powerless as LLM companies want you to believe.

A key problem here seems to be that domain based outbound network restrictions are insufficient. There's no reason outbound connections couldn't be forced through a local MITM proxy to also enforce binding to a single Anthropic account.

It's just that restricting by domain is easy, so that's all they do. Another option would be per-account domains, but that's also harder.

So while malicious prompt injections may continue to plague LLMs for some time, I think the containerization world still has a lot more to offer in terms of preventing these sorts of attacks. It's hard work, and sadly much of it isn't portable between OSes, but we've spent the past decade+ building sophisticated containerization tools to safely run untrusted processes like agents.

> We TOLD you this dynamic web stuff was a mistake. Static HTML never had injection attacks.

Your comparison is useful but wrong. I was online in 99 and the 00s when SQL injection was common, and we were telling people to stop using string interpolation for SQL! Parameterized SQL was right there!

We have all of the tools to prevent these agentic security vulnerabilities, but just like with SQL injection too many people just don't care. There's a race on, and security always loses when there's a race.

The greatest irony is that this time the race was started by the one organization expressly founded with security/alignment/openness in mind, OpenAI, who immediately gave up their mission in favor of power and money.

Germany was a split country for 50 years.

Korea is still a split country.

I guess I have to give you Japan, although now you could say "clearly the solution is nukes" if you're just going blindly on data.

Even if you think it's going to go well this time, you have to admit this sort of thing does not have a good track record.

Productivity gains are more likely to be used to increase margins (profits and therefore value to shareholders) then it is to reduce work hours.

At least since the Industrial Revolution, and probably before, the only advance that has led to shorter work weeks is unions and worker protections. Not technology.

Technology may create more surplus (food, goods, etc) but there’s no guarantee what form that surplus will reach workers as, if it does at all.

Citation needed?

I spend $0 on AI. My employer spends on it for me, but I have no idea how much nor how it compares to vast array of other SaaS my employer provides for me.

While I anecdotally know of many devs who do pay out of pocket for relatively expensive LLM services, they a minority compared to folks like me happy to leach off of free or employer-provided services.

I’m very excited to hopefully find out from public filings just how many individuals pay for Claude vs businesses.

Thanks! That’s some nuance I absolutely missed

It’s a fun demo but they never go into buildings, the buildings all have similar size, the towns have similar layouts, there’s numerous visual inconsistencies, and the towns don’t really make sense. It generates stylistically similar boxes, puts them on a grid, and lets you wander the spaces between?

I know progress happens in incremental steps, but this seems like quite the baby step from other world gen demos unless I’m missing something.

> Really, setting the interval balances speed of detection/cost of slow detection vs cost of reacting to a momentary interruption.

Another option is dynamically adjusting heartbeat interval based on cluster-size to ensure processing heartbeats has a fixed cost. That's what Nomad does and in my 10 year fuzzy memory heartbeating has never caused resource constraints on the schedulers: https://developer.hashicorp.com/nomad/docs/configuration/ser... For reference clusters are commonly over 10k nodes and to my knowledge peak between 20k-30k. At least if anyone is running Nomad larger than that I'd love to hear from them!

That being said the default of 50/s is probably too low, and the liveness tradeoff we force on users is probably not articulated clearly enough.

As an off-the-shelf scheduler we can't encode liveness costs for our users unfortunately, but we try to offer the right knobs to adjust it including per-workload parameters for what to do when heartbeats fail: https://developer.hashicorp.com/nomad/docs/job-specification...

(Disclaimer: I'm on the Nomad team)

If any of the super wealthy people actively promoting this fantasy actually believed it they wouldn’t be so worried about amassing wealth today. "Over abundance" talk happened during previous technological revolutions too: at best it was just silly over optimism, at this point I tend to think they’re just obliquely preparing us for underemployment and lower incomes.

Who orchestrates the orchestrators? is the question we’ve never answered at HashiCorp. We tried expanding Consul’s variety of tenancy features, but if anything it made the blast radius problem worse! Nomad has always kept its federation lightweight which is nice for avoiding correlated failures… but we also never built much cluster management into federated APIs. So handling cluster sprawl is an exercise left to the operator. “Just rub some terraform on it” would be more compelling if our own products were easier to deploy with terraform! Ah well, we’ll keep chipping away at it.

Fair enough. I suppose there aren’t many hard real time posts these days in general.

It has to be AI generated or at least edited right? The reliance on bulleted lists. The endless adjectives and declarations. ...but also the subtle... well not exactly errors, but facts I think are open to dispute?

Such as:

> Together, these tools make Go perfect for microservices, real-time systems, and high-throughput backends.

Real-time systems?! I have never heard of anyone using Go for realtime systems because of its GC and preemptive scheduler. Seems like the sort of thing an LLM would slip in because it sounds good and nails that 3 item cadence.

> Built on top of Go channels → broken backpressure.

But then the example is about ordering. Maybe I'm being pedantic or missing the specific nomenclature the ReactiveX community uses, but backpressure and ordering are different concerns to me.

Then the Key Takeaways at the end just seems like an LLMism to me. It's a short article! Do we really need another 3 item list to summarize it?

I'm not anti-LLM, but the sameness of the content it generates grates on me.

The supposedly bad example is perfectly readable to anyone familiar with Go. A bit of refactoring into first class functions, and you'd have an easy to read, idiomatic, easy to test, well typed code base with obvious places to adjust useful behaviors like concurrency limits.

Meanwhile the samber/ro example is incomplete (Subscribe(...)?), and the source includes some weird stuff: https://github.com/samber/ro/blob/22b84c8296c01c4085e8913944...

Not to mention heaps of reflection and panics: https://github.com/samber/ro/blob/22b84c8296c01c4085e8913944...

The functionality and expressiveness might be fantastic, but I would evaluate it very carefully before use.

> Benioff said he “avidly supported President Trump”

http://timesofindia.indiatimes.com/articleshow/124475145.cms

The snippet included in the search result does not include or highlight the relevant fact. I feel like you’re not willing to take simple actions to confirm your assertions.

I do, and so does Google. When I googled "When was John Howard elected?" the correct answer came back faster in the AI Overview than I could find the answer in the results. The source the AI Overview links even provides confirmation of the correct answer.

I'm a Go developer and this was still useful for me! Obviously Rust devs are more accustomed to more assistance from their tools than Go devs, but just about every gotcha listed is something that can happen in Go with goroutines, channels, select, and other shared concurrency primitives.

Sadly capabilities are older than emacs. I’d welcome advancements here but their practical utility is clearly not a foregone conclusion.

vim and emacs are over 30 years old and therefore living with an architecture created when most code was trusted. Encrypting network protocols was extremely rare, much less disks or secrets. I don't think anything about the security posture of vim and emacs should be emulated by modern software.

I would say VSCode has no excuse. It's based on a browser which does have capabilities to limit extensions. Huge miss on their part, and one that I wish drew more ire.

One of the large dependencies they call out is an excellent example: pdf.js.

There is no reason for pdf.js to ever access anything other than the files you wish to export. The Export to PDF process could spawn a containerized subprocess with 0 filesystem or network access and constrained cpu and memory limits. Files could sent to the Export process over stdin, and the resulting PDF could be streamed back over stdout with stderr used for logging.

There are lots of plugin systems that work this way. I wish it were commodofied and universally available. AFAIK there's very little cross-platform tooling to help you solve this problem easily, and that's a pity.

The Simpsons Springfield Nuclear Plant Security scene in real life.

https://www.youtube.com/watch?v=eU2Or5rCN_Y