Comments URL: https://news.ycombinator.com/item?id=48467648

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48449424

Points: 19

# Comments: 0

Or at least the app’s logo is the root user symbol: a number sign [2]

Normal users typically get a $ prompt, while the superuser (root) gets a # prompt [3]

[1] https://wiki.debian.org/Root

[2] https://en.wikipedia.org/wiki/Number_sign

[3] https://unix.stackexchange.com/a/291733

Comments URL: https://news.ycombinator.com/item?id=48390029

Points: 3

# Comments: 0

I’m trying to create an account to test this service. I get this error message, what does it mean? Why is the error message so short to the point where I (the user) don’t know what to do next? Why can’t software developers learn how to communicate better with their non-tech users? And this is coming from someone with a 30+ years career in software engineering.

edit: after hitting the button “I’ve saved my recovery phrase - continue” multiple times and getting the same repeated error message, it finally worked but then the API returned “error: Registration failed”. And at this point I give up. This is why many projects, even at Big Tech companies, fail: too much friction for new users, or too many features, or too many options to choose from.

I don’t know the specifics of this case, but I’ve managed bug bounty programs in the past through Bountysource and HackerOne. One thing that occasionally happens is that a report makes its way to the development team before the security team has fully assessed it, in this case MSRC.

At that point, a developer may decide to quietly fix the issue. Sometimes that’s driven by a concern, rational or not, that being associated with a security bug could reflect poorly on them or affect future promotion opportunities. The result is that by the time the security team attempts to reproduce the report, the vulnerability is already gone.

From MSRC’s perspective, all they see is that the provided reproduction steps no longer work. They have no visibility into the internal history of the bug or whether someone already patched it. As a result, the report gets closed as invalid even though the original finding may have been legitimate.

These days, the problem with cloud-hosted Git platforms is not where to push your code. Replicating repositories across multiple providers is relatively easy, and Git has always been good at that. The harder problem is that successful teams end up accumulating a lot more than source code around their repositories, and much of that information becomes just as important as the code itself.

Bug reports, feature requests, documentation, design discussions, code reviews, project planning, CI/CD configuration, and years of historical context all tend to live inside platforms such as GitHub. While the Git repository itself is portable, all of that surrounding data is often much harder to migrate cleanly, especially if a team has built workflows and integrations around a particular provider.

That, in my view, is one of the main reasons so many companies are heavily dependent on GitHub. Moving the code elsewhere is usually straightforward; moving the entire development process, with all of its history, metadata, and institutional knowledge, is not. When GitHub goes down, the question is often less about where you can push your next commit and more about how easily you can recreate the rest of the environment that your team relies on every day.

• ussea4-edge-fx-012.aaplimg.com

• mensura.cdn-apple.com/api/v1/gm/large

People from my generation aren’t buying Calbee because the bag is colorful. They’re buying it because it’s Calbee and they already know what they’re getting. The packaging could be black and white and I’d still recognize it instantly.

The only people I could see being briefly confused are younger consumers. Japanese packaging tends to be very colorful, so we’re all conditioned to identify products partly by color. But people adapt quickly. In fact, a black-and-white Calbee bag might end up standing out more on a crowded supermarket shelf than yet another brightly colored package.

There’s also a chance this ends up being a net positive. If simpler packaging lowers costs and sales stay the same, why go back? Japanese consumers are feeling inflation more than they have in decades, and companies are under pressure too. Cutting costs in a place customers barely notice seems a lot smarter than shrinking the product or raising prices again.

Way too many companies have figured out that exaggerating, misleading, or outright lying gets them headlines, investors, and free marketing long before anyone verifies the claims.

A company cannot literally “hate” anyone. It has no feelings, intentions, or consciousness. So who exactly is supposed to hate you here? The CEO? The executives? The leadership team? Every single employee at Google? And who is “you,” exactly? Billions of users spread across the planet?

I get the point the title is trying to make, but it feels more accurate to say that Google optimizes for incentives that are often misaligned with users, not that it emotionally despises them.

Comments URL: https://news.ycombinator.com/item?id=48295869

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48188363

Points: 4

# Comments: 0

Indeed… That evolution makes perfect sense. A lot of Go developers independently arrived at similar request coalescing patterns around that time, especially in caching, RPC, and high concurrency systems. I have an older implementation from personal 2013-era Go projects that follows almost the same approach.

What is nice about open source is not necessarily the novelty of every individual idea, but having a well-tested, shared implementation the community can converge on. Your work on singleflight clearly became that reference point for the Go ecosystem, and it is cool to see the lineage from dl.google.com to groupcache, x/net, the standard library, and now all the downstream variants.

How long do people realistically expect a laptop to stay competitive with SOTA local models? Especially in a space where model sizes, context windows, and inference requirements keep moving every year.

And even if the hardware lasts, the local experience usually doesn’t. A heavily quantized local model running at tolerable speeds on consumer hardware is still nowhere near frontier hosted models in reasoning, coding, multimodal capability, tool use, or reliability.

The economics just don’t make sense to me unless you specifically need offline inference, privacy guarantees, or low latency for a niche workflow. Otherwise you’re tying up $10k upfront to run an approximation of what you can already access through a subscription that continuously improves over time.

You could literally put the difference into index funds and probably cover the subscription indefinitely from the returns alone, even accounting for gradual price increases.