HN user
I don’t need “a varied sense of taste” to save money on gas and non-perishables.
I don’t need “a varied sense of taste” to budget and do simple math to determine the membership is worth it.
Babies don’t need “a varied sense of taste” to use diapers purchased from Costco in bulk at a great price.
Do I lack a “varied sense of taste” when I buy ingredients from Costco, like chicken thighs and rice and eggs and olive oil, and cook them at home?
Right. License pulls happen extremely rarely for digital video games[1]
And delisting a game from a store isn't a license pull. Delisting prevents new purchases of the game, but owners of a game prior to delisting can still download and play[2]
For example, even though Sony is closing the PS3 store to new purchases after 20 years, existing owners of digital games can still download their digital copies. So my entire PSN digital library for the past 20 years is still downloadable and playable. Same for Steam.
I love GOG, and prefer a DRM-free digital copy for PC that I can backup redundantly, as it is the most future-proof option, IMO. Physical media can get damaged or lost and digital storefronts won't last forever (even Steam could shut down one day). Even my hard drives can fail and lose data. But even so, when I purchase a digital license for a game, I have good confidence it will be playable for years and years to come.
---
1. Of course, many online multiplayer games have had their servers shut down, after which the game becomes effectively unplayable. But this is a separate problem that isn't solved by choosing physical over digital media.
2. As long as the digital storefront exists and as long the console hardware still works, if I purchased it for a console.
This more a dig at Sony than a reason Valve can’t also sell their hardware as a loss leader. They are massively profitable from their cut of Steam sales anyway. And part of PS Plus is a catalog of games and monthly games, similar to Gamepass. Valve could easily have a profitable subscription model for games or services if they wanted to.
AFAIK, Golang's module system (mentioned in the article) protects against this. From [1],
The revision must be an ancestor of one of the module repository’s branches or tags. This prevents attackers from referring to unapproved changes or pull requests.
if you go look at any real Go projects they usually use tons of dependencies and they're usually pinned to random git hashes
No, they are usually pinned to a git tag, which is usually a version string representing a released version. And the tag is locked to a hash to detect if the tag is later modified.
I left the Python ecosystem some time ago.
Reasons: The Python 2->3 transition, asyncio package, async/await function coloring, abysmal package management, the GIL and poor performance, breakage from version to version. I'm ambivalent on type hints. I regret nothing, especially after seeing how the GC and JIT projects have been handled.
Golang addresses all of my problems with Python. Native code, good performance, an exceptional toolchain, a built-in package solution, great concurrency support, and they prioritize compatibility across versions. AI is good at writing Golang (as good as any other language I've tried), and AI benefits a lot from static types.
It is because female mosquitos only mate once in their lifetime.
Ah. So multiple billion actions per month, and probably multiple million dollars per year on their cloud, if they can even support that load (plus, the vendor lock in and etc). Makes sense.
Honest question: Can you use Temporal Cloud? Have you evaluated Temporal Cloud pricing?
Ballparking: 200 events/workflow, 200 workflows/per day and assuming 1 event = 1 cloud action[1], that is 1.2M or so actions per month. The $100/month plan includes 1M actions each month, and even the pay-as-you pricing when you exceed that is $50 per 1M actions[2].
Temporal Cloud seems extremely cheap for your use case, even if I'm off by a factor of 10. Is there a catch? You still need infra to run your Temporal workers, and I assume there are storage and other costs, but I assume action usage is the majority of it.
1. Not sure exactly what constitutes an "Action". At a glance, seems like most events have a corresponding action(?) and a subset of those actions are actually billable(?)
2. https://docs.temporal.io/cloud/pricing#payg-action-pricing
Yeah, I'm probably wrong there. GPT OSS 20B is certainly much faster than some other models I've tried. I actually gave GPT OSS 20B a few prompts just now and it seems to respond as fast or faster than Qwen 3.5 9B. But I needed many more prompts for GPT OSS 20B to complete my contrived task, so progress felt much slower.
I could have used this article before I spent the weekend arriving to the same conclusion!
Same laptop, and my contrived test was having it fix 50 or so lint errors in a small vibe-coded C++ repo. I wanted it to be able to handle a bunch of small tasks without getting stuck too often.
GPT OSS 20B was usable but slow, and actually frequently made mistakes like adding or duplicating statements unnecessarily, listing things as fixed without editing the code, and so on.
Qwen 3.5 9B with Opencode was much faster and actually able to work through a majority of the lint warnings without getting stuck, even through compaction and it fixed every warning with a correct edit.
I tried 4bit MLX quants of Qwen 3.5 9B but it eventually would crash due to insufficient memory. I switched to GGUF, which I run with llama.cpp, and it runs without crashing.
It is absolutely not comparable to frontier models. It’s way slower and gets basic info wrong and really can’t handle non trivial tasks in one go. I asked it for an architecture summary of the project and it claimed use of a library that isn’t present anywhere in the repo. So YMMV, but it’s still nice to have and hopefully the local LLM story can get much better on modest hardware over time.
Well, the TI-83/84 are called a graphing calculators for a reason: you can plot equations and datasets with them and look at them right there[1]. Looking at graphs is huge for learning, or at least it was for me, and school isn't just about plugging things in and getting an answer (or shouldn't be, at least).
Doesn't mean it's not overpriced, but that's one reason and you can get a used TI-83/84 for like $30 or less. They pretty much never break.
-----
1. Okay, the Casio can QR-code-link you to a graph, but if I have internet/smartphone there are better graphing tools anyway, like Desmos.
Writing the code hasn’t been the bottle neck to developing software for a long time.
Code may not be the bottleneck, but writing it absolutely does consume time.
Especially with solo game dev, I can prototype ideas, try them out, and then refine or scrap them at a rate I could never do without AI. This type of experimentation is a perfect use-case for AI. It’s actually super fun, and if I pay attention and give the AI decent instructions, I don’t really lose out on code quality.
If you’re asking about a population decrease then, no, Austin has not had a declining population count for decades, and not recently either, although growth has slowed. So it’s not a case of decreased demand.
You are comparing it to other Apple laptops but you should be comparing with its competition at a $600 price point. The aluminum enclosure, touchpad, battery life, display, and performance are all best in class (or near enough) at this price point.
I mean, let’s at least discuss this in good faith.
“Good” bread according to the majority and bread that is specifically up to your standards are probably two very different things.
My grocery store’s bakery sells many types of fresh bread: sourdough, white, rye, croissants, ciabatta, buns, rolls, bagels, and so on. Many grocery stores in my city have a bakery section with a selection of fresh bread like this. (Even Walmart I think, but I don’t shop there).
It’s not the best bread I’ve ever eaten, but it’s fresh, good, tasty bread. It’s not “mushy garbage” and it’s not “cake” like you described in your original comment. It’s not “weird specialty hipster” bread. It’s just simple, real, fresh bread.
They don’t because of at-will employment. It’s just sort of the more moral, empathetic, right thing to do instead of leaving them with no income, no insurance, etc.
Good bread is everywhere in major cities in the US. There are bakery sections at grocery stores and there are many local bakeries.
Oh true. Considering inflation, $60 in 2016 is about $80 in 2026 so really the price has gone down in real terms.
(Not actually sure about the price history of the family plan or when family was introduced. I was originally on the individual plan and it was $35 then, and switched to the family plan in 2022. I don’t think prices have changed though)
My family pricing went up by 20%, from $59.88 USD to $71.88 per year.
I like 1Password a lot. I've used it for 10 years. It's never lost a single thing, and I don't recall any downtime that impacted me. It's easy to setup and 99% hassle free. Works on my various device types (windows, mac, ios). It supports passkeys and 2FA codes. I like having shared and private vaults. I love the ability to share an auto-expiring, one-time-view link to a password. And the billing is a simple subscription fee.
I could do without some bloat. Watchtower feels like an enterprise need that is otherwise low-value and (by default) noisy for individuals/families. I obviously don't need "AI" forced into my password manager. I didn't love the version 7 to 8 transition that required a new app/extension to be installed. But all of that is really not so bad.
So yeah, I don't feel like I'm getting any additional value that justifies the price increase, but it's still more than worth it for me.
It's a good idea. There are many studied benefits to (intermittent) fasting, for example: https://pmc.ncbi.nlm.nih.gov/articles/PMC11262566/
I don’t agree.
She has posted publicly about her condition.
He is 25 years old and trying to cope with a hard life event. Let’s not act like it doesn’t affect him. It affects everyone around her and the strong reaction from him is really a positive reflection on her, isn’t it?
His post is written and edited to garner sympathy and support. I don’t mind that for a naive but noble cause. And there is always a slim chance of success.
Sort of for sake of argument: National obesity statistics don’t necessarily imply anything about the healthiness of the food, nor specifically about the healthiness of $4 lunches that the article discusses. If the Japanese eat smaller portions and are less sedentary, they could still be less obese regardless of differences in the nutritional content of these $4 lunches. (And I think they ARE less sedentary and DO eat smaller portions.)
I’m not advocating for anything (certainly not optimizing for calories per dollar).
My point is just that the article has no data. It says a Japanese lunch is cheap and a US lunch is expensive and doesn’t consider what you actually get for the money. It assumes the US lunch is a worse deal, but I suspect it’s really not if you adjust the price for the amount of food.
Supposedly there is no data shared with Google when using Gemini-powered Siri:
Google’s model will reportedly run on Apple’s own servers, which in practice means that no user data will be shared with Google. Instead, they won’t leave Apple’s Private Cloud Compute structure.[1]
1: https://9to5mac.com/2025/11/05/google-gemini-1-billion-deal-...
I'm not sure what your point is. Is it about the lunches being specifically healthy?
A rice bowl at Chipotle, for example, is not unhealthy (rice, beans, meat, vegetables). Plenty of restaurant food in the US is perfectly healthy (or, you can look at nutrition facts to know if it is). And if I can take a single US portion size and split it into two lunches that are Japanese-sized portions, then maybe we're getting the same amount food per dollar.
And on the "healthy" point: The article doesn't discuss nutrition facts at all or refer to any specific meals or dishes.
They link to an article concerning the price of Japanese bowls, that mentions "a regular-sized bowl of rice with beef from Japanese fast food chain Yoshinoya, which costs around 468 yen (S$4.25)." I don't know Japanese so it's hard for me to find nutrition information about that particular dish, but I suspect that a beef bowl is high in saturated fat, cholesterol, and sodium (because most stir-fried beef is higher in these things). Is that healthy? Japan as a country has higher sodium intake than the US. Is that healthy? And so on. I suspect a big factor of the "health" of these lunches is that portion sizes are just smaller than in the US (but I have no data).
This needs more detailed data that normalizes for the amount of food (price per calorie or price per weight or something like that).
Yes, a bowl at chipotle in the US might be 2x the price (more, probably) of a Japanese bowl, but it matters if I am getting 2x the calories also.
And there are foods in the US that are technically as cost effective, although maybe not as nutritious, like pizza which they mention, that can be around $1-$3 per slice. (Not my first choice for a lunch, but I could pickup a large 3 topping dominos pizza for $10 and make 3-4 lunches out of it, for example)
Agree to disagree I guess, but IME, git history is good for low level detail, not for high level information. Git history is a poor source for understanding architecture, code organization, and other aspects of the codebase. More often, git commit messages tell me what changed - not why the change was made or who it impacted or etc.
Reading through git history should be my last resort to figure something out about the codebase. Important knowledge should be written somewhere current (comments, dev docs, etc). If there is a random value being appended to a url, at least a code comment explaining why so I don’t even have to git blame it. Yes, these sources of knowledge take some effort to maintain and sure, if I have a close-knit team on a smaller codebase, then git history could suffice. But larger, long-lived codebases with 100s of contributors over time? There’s just no possible way git history is good enough. I can’t ask new team members to read through thousands of commits to onboard and become proficient in the codebase (and certainly not 5x-10x that number of commits, if we are not squashing/rebasing feature branches into main. Although, maybe now an LLM can explain everything). So I really need good internal/dev documentation anyway, and I want useful git history but don’t care so much about preserving every tiny typo or formatting or other commit from every past feature branch.
Also iirc, with github, when I squash merge via the UI, I get a single squashed commit on main and I can rewrite the commit message with all the detail I like. The PR forever retains the commit history of the feature branch from before the squash, so I still have that feature branch history when I need it later (I rarely do) so I see no reason to clutter up history on main with the yucky feature branch history. And if I tend toward smaller PRs, which is so much nicer for dev velocity anyway, even squashed commits can be granular enough for things like bisect, blame, and so on.
Using git history as documentation is hacky. A majority of feature branch commit messages aren't useful ("fix test case X", "fix typo", etc), especially when you are accepting external contributions. IF I wanted to use git history as a form of documentation (I don't. I want real documentation pages), I'd want the history curated into meaningful commits with descriptive commit messages, and squash merging is a great way to achieve that. Git bisect is not the only thing I do with git history after all.
And if I'm using GitHub/Gitlab, I have pull requests that I can look back on which basically retain everything I want from a feature branch and more (like peer review discussion, links to passing CI tests, etc). Using the Github squash merge approach, every commit in the main branch refers back to a pull request, which makes this super nice.
Right, but they are referring to configuration on a GitHub repository that can make squash merge automatic for all pull request merges.
e.g. When clicking the big green "Merge pull request" button, it will automatically squash and merge the PR branch in.
So then I don't need to remind or wait for contributors to do a squash merge before merging in their changes. (Or worse, forget to squash merge and then I need to fix up main).
Rebasing replays your commits on top of the current main branch, as if you’d just created your branch today. The result is a clean, linear history that’s easier to review and bisect when tracking down bugs.
The article discusses why contributors should rebase their feature branches (pull request).
The reason they give is for clean git history on main.
The more important reason is ensure the PR branch actually works if merged into current main. If I add my change onto main, does it then build, pass all tests, etc? What if my PR branch is old, and new commits have been added onto main that I don't have in my PR branch? Then I can merge and break main. That's why you need to update your PR branch to include the newer commits from main (and the "update" could be a rebase or a merge from main or possibly something else).
The downside of requiring contributors to rebase their PR branch is (1) people are confused about rebase and (2) if your repository has many contributors and frequent merges into main, then contributors will need to frequently rebase their PR branch, and each rebase their PR checks need to re-run, which can be time consuming.
My preference with Github is to squash merge into main[1] to keep clean git history on main. And to use merge queue[2], which effectively creates a temp branch of main+PR, runs your CI checks, and then the PR merge succeeds into main only if checks pass on the temp branch. This approach keeps super clean history on main, where every commit includes a specific PR number, and more importantly minimizes friction for contributors by reducing frequent PR rebases on large/busy repos. And it ensures main is never broken (as far as your CI checks can catch issues). There's also basically no downside for very small repos either.
1. https://docs.github.com/en/repositories/configuring-branches...
2. https://docs.github.com/en/repositories/configuring-branches...