HN user

dbmnt

108 karma
Posts1
Comments100
View on HN

Yes but parent was saying use passphrases, which is the same, just more like "correct horse battery staple". Parent then correctly pointed out there are a large number of sites that enforce special characters, numerical digits, etc., also being part of the password. So that idea falls apart very quickly in practice.

But more specifically why build a stack tied to a single vendor?

You talk about competent SRE being hard to find and manage but then you describe needing several AWS backend specialists.

I think I'd rather have a generalized SRE team with portable infrastructure.

Maybe that's just me. I watched an org get burned by Google App Engine. I find these proprietary stacks to be a giant trap.

I built a news aggregator that pulls in hundreds of RSS feeds and uses multiple large language models to synthesize daily briefs. There's also Tech and Finance editions, plus local editions for some US locales. https://feedpunk.com

I'm also building a modern HTTPS-only transport utility called curb. It's an alternative to curl and wget. It's written in Go using only the standard library. curb can stream output or download files and picks the right behavior based on what the server returns and whether the output is going to a human or a pipe. It also has a '--vet' mode that runs the body through security sieves; this is meant to add some protection and friction for the 'curl | sh' use-case. https://gocurb.dev

I hear you on IP law, but how it applies to AI training is far from settled.

I don't believe we should have software patents, and I am highly skeptical of the US copyright system in general.

As for why I didn't use a piracy analogy: humans don't need to pirate books to access them for free. They can just go to the library. That is exactly my point. Reading books isn't a crime. Why would we stop an AI from reading publicly available material just because it's automated and upsets the commercial status quo?

"Amazon's CEO knew what he was doing" is not a fact. That's speculation.

When it comes to highly technical, fast moving developments like frontier AI and blue team / red team perspectives, I could see any CEO getting out over their skis. Now mix in some incompetent Trump admin officials, including apparently Howard Lutnick. I am guessing many of these people don't understand the subject matter very well at all.

Imagine a super intelligent speed reading human in a library. If they read all the books and are able to understand, conceptualize and summarize that knowledge for others, is it theft? The books weren't stolen, after all, just read. The knowledge in the books wasn't taken away; it's still there for others to read.

I personally do not believe knowledge can be stolen.

Open 3 terminal windows. Try to switch back & forth between just two of them with a keyboard shortcut

cmd+` gets me there, no problem at all

Open a browser and two terminal windows. Try to switch terminal and the browser window, without also bringing the other terminal above the browser window

you got a point there. alt+tab is gonna surface both terminal windows above the browser.

Gboard hasn't been updated in 4 years and as a result the UI doesn't always display properly. It's especially jarring on iOS 26. It doesn't fit into the OS keyboard target area properly (on my iPhone 17 Pro, at least).

I've tried pretty much every reputable third-party keyboard app in the App Store. Unfortunately, there's really nothing better than the stock one.

I’m struggling with the utility of this logic. The argument seems to be "because malware can intercept /proc output, any tool relying on it is inherently unreliable."

While that’s theoretically true in a security context, it feels like a 'perfect is the enemy of the good' situation. Unless the author is discussing high-stakes incident response on a compromised system, discarding /proc-based tools for debugging and troubleshooting seems like throwing the baby out with the bathwater. If your environment is so compromised that /proc is lying to you, you've likely moved past standard tooling anyway.

I just installed it and it seems really promising. Glad you shared it here.

I’ve spent more time than I care to admit searching for a good keyboard app in the App Store, and I’ve tried a lot of them. This one never surfaced for me in any of my usual searches, which is a shame (likely more on Apple’s search than on you).

I really like the T9-style approach, and I appreciate the clean App Privacy section and straightforward privacy policy.

It's right there in the FAQ.

"Your Affinity V2 license (via Serif) remains valid and Serif will continue to keep activation servers online. But please note that these apps won’t receive future updates."

This is wrong. It shows a fundamental misunderstanding of how certificate authorities (CAs) work.

A certificate has to be signed by a trusted CA (one your browser already trusts).

A DNS provider could mint a self-signed cert for pornhub.com, but your browser would reject it immediately.

Even if they tried to trick a real CA, Certificate Transparency (CT) would expose the bogus certificate:

https://en.wikipedia.org/wiki/Certificate_Transparency

Instead, NextDNS is very likely abusing the EDNS Client Subnet feature to provide website operators with a spoofed client location. Much more simple and less nefarious.

I’m also puzzled by the Instant On divestiture. In the original filing and press release the DOJ does call out SMB, even though most of the discussion is about enterprise markets:

https://www.justice.gov/opa/pr/justice-department-sues-block...

My guess is that by forcing HPE to spin off Instant On, the DOJ hopes to score a modest PR win by claiming it protected small businesses, by preserving one of the few turnkey, cloud-native wireless solutions for SMBs. Since Instant On represents only a tiny portion of the deal, though, it seems odd that it was singled out.

Acquisitions have been central to Hewlett-Packard’s strategy since the mid-1980s. Just look at this list:

https://en.wikipedia.org/wiki/List_of_acquisitions_by_Hewlet...

HPE consistently struggles to retain talent and foster growth post-acquisition. Integration is hampered by decades of IT cruft, leading to a sluggish tech stack and a deeply bureaucratic culture. Like many public companies, they also suffer from a lack of long-term focus.

Aruba Networks (acquired by HP in 2015, right before HP split into HP/HPE) has approximately 5% of the market for switching outside of the datacenter segment. They aren't a big player in the DC, you're right about that.

Google used to use HP (pre Aruba) switches in the DC in the early days. Not many though. Mostly for OOB access. I doubt they still do.

Google's non-AI efficiency is not much better than Amazon or anyone else.

I don't think this is true. Google has long been a leader in efficiency. Look at the power usage effectiveness (PUE). A decade ago Google announced average PUEs around 1.12 while the industry average was closer to 2.0. From what I can tell they reported a 1.1 average fleet wide last year. They've been more transparent about this than any of the other big players.

AWS is opaque by comparison, but they report 1.2 on average. So they're close now, but that's after a decade of trying to catch up to Google.

To suggest the rest of the industry is on the same level is not at all accurate.

https://en.wikipedia.org/wiki/Power_usage_effectiveness

(Amazon isn't even listed in the "Notably efficient companies" section on the Wikipedia page).

I'm using Kagi as my default, falling back to Google (typically via '!g' in Kagi) for some technical queries. I use ChatGPT 4o several times a day, but typically not as a 1:1 replacement for web search.

My guess after reading the same -- the bot traffic comes in bursts and targets a specific commit hash for a while. Users are unlikely to need that specific commit, and even less likely to need it at the same time a bot is bursting requests for it. There's probably a small risk of denying a real user, but there's a large reduction in traffic from the bots making it to git; a worthwhile trade.