admax88qqq

Somebody (Mozilla?) should make a browser that just proactively blocks shit like this

I’m sure some Adblock addon could do it but at the browser level would be preferred. A browser vendor that just proactively does security and “correctness” tweaks to live sites would actually be in my interests as a user

why a non-decreasing counter?

Looking at your solution, if i understand it, is instead of decreasing the inventory count for each sku as orders are processed, you are comparing the current warehouse quantity against the sum of all carts to see if there's availbale quantity.

You'll have to also include the sum of all completed orders so far.

Honestly seems almost worse? Arn't you trading contention on a single counter (inventory) for a large read across all pending and completed orders? Even indexed you're ingesting a ton more data? And you'll still need a lock here as you have to ensure two orders do this check at the same time.

Naive design

- Single inventory row per warehouse sku - All orders compete on a lock for all inventory sku rows in their order to deduct/claim their items

Shopify design

- Unroll warehouse inventory to thousands of rows per sku - Order processing races to find sufficient unlocked rows for all items in order - If insufficient rows are found then orders block behind slower "restock" process that creates more rows

Your design

- Warehouse inventory row is static/read-only (restocking out of scope for now that's fine). - Order processing computes the sum of all completed orders to ensure there is sufficient quantity - This would have to be under a lock as well, otherwise two or more racing orders will think there is quantity left.

So sounds like in your solution, you still have a single point of contention for who is computing the sum of completed orders, and while holding that lock you are doing a sum of all completed orders for each sku in your order. That sounds... worse?

> Shopify incorrectly formulated the very problem they are trying to solve.

That’s a bold overconfident statement. Cart abandonment is real. People never clear their carts they just walk away

Shopify purposefully chooses to do it at payment time because doing it earlier results in lost sales as people “reserve” items and then walk away causing other to see out of stock and then also walk away

Whoever puts up the money first gets the item

That’s the design constraint they chose you can’t just say “their solution is wrong because they solved the wrong problem”. Each design is a different user experience and I think it’s safe to say they chose which experience they want consciously.

don't you then have to keep your IDE config synced across them an open a whole instance for each project? Why even have an OS underneath it at this point?

Sometimes it feels like I'm just being asked to install a real linux distro inside my linux distro so I can actually do things. Here's you nice shiny desktop and app store! Oh you want to do more than browse the web? Better install linux again in a VM.

Maybe i'm just stuck in legacy paradigms, but I kind of like just booting IntelliJ and picking the project i'm on today.

Or sometimes I want to move stuff between projects i'm working on, that's a lot easier if my one IDE instance can hit them all at the same time.

I think ultimately you still have to pay down tech debt eventually. Either through bankruptcy (throwaway the project) or servicing the debt (refactoring, rearchitecting etc).

It's not different than when coding by hand, often we take shortcuts by hand that we then have to pay for later. It really just becomes a judgement call on when to stop prompting new features and start service what you have.

I think with AI and vibecoding its tempting to assume the output is good and chase the dopamine hits of more features, more features, more features, but eventually you get stuck.

That being said AI is also a great tool at paying down tech debt. It's great at helping you read a codebase and can be great at making the mechanical changes you want. And I think there is some truth to the story that newer models will be able to pay down debt (fix the slop) of older models. But its all shades of grey, newer models are better than older ones, but can I emit slop with 5.6 faster than 5.7 will be able to fix it in the future? Nobody knows.

It's not like human projects are devoid of bad code, its all tradeoffs and shades of gray. But to be honest I haven't written a line of code by hand in a while.

mostly i'm trying to get out of the terminal and most IDEs don't understand devbox/distrobox well without lots of finagling.

Sure but that's orthogonal.

Yes you use the right tool for the job.

But if the job requires the best intelligence you can get with an LLM, then you use that.

Taking as an assumption that the quality of your product is a function of the quality of the inference you are using: if you use an inferior model because "what if it gets export controlled again" and your competitors don't, then your competitors are likely to win.

If you don't need frontier models for you job then this is all moot, but the thread started with

> You cannot build a business critical function on top of American SOTA frontier model

Which is silly. HN likes to roleplay bringing everythgin "business critical" in house because sometimes vendors mess up. Self host, don't use the cloud, run open models locally, built redundant supply chains in case of another covid, etc etc. Sometimes the risk is real, but most of the time the risk is rare and the cost of an interruption event is less than the cost of bringing everything in house or using lower quality vendors "just in case"

> beats Claude in our Cyber Benchmarks

Beats which model in Claude? Whenever a "benchmark" doesn't put precise model numbers in their headlines I am immediately skeptical. Either they don't know the difference (bad) or they are benchmarking against weaker models (misleading, also bad).

It's like when studies say "AI is bad at X" and they used GPT-3.5 in current year.

> One day, maybe not far from now, a breakthrough will allow huge LLMs (say 200B in size) to run well on an old 5 year old Dell desktop.

But if you have such a breakthrough could you not also apply it and run 200T models on todays datacenters?

The conspiracy version of this is each bad windows release is purposefully extra bad so the next "good" version is perceived as artifically well.

It's a shame too, I feel like the underlying OS has some really good engineering in it, but the layers of cruft and anti-features on top make for a poor overall product.

This follows the standard windows pattern of every release alternating between bad/good.

98 good

ME bad

XP good

Vista bad

7 good

8 bad

10 good

11 bad

When 12 comes windows will be tolerable again.

I would wager all of those are distributing malware.

> This looks increasingly a good idea.

Why?

Right I get tha. The point I’m making is that from a users perspective it’s functionally very similar. A non deterministic llm or a non deterministic company full of designers and engineers.

Web apps kind of already do that with most companies shipping constant UX redesigns, A/B tests, new features, etc.

For a typical user today’s software isn’t particularly deterministic. Auto updates mean your software is constantly changing under you.