locknitpicker

Using more tokens is a significant problem if you pay per token?

Yoh have posts in this thread suggesting that Fable is 5x more expensive than Kimi K3.

or the web app task I mentioned:

* Kimi K3: (...) cost $6.3

* Fable: (...) cost $30

It's pretty clear that Kimi K3 beats Fable by a long margin.

though I own a half-dozen YubyKeys, I do wonder what their profit margins are.

I hope they are huge while the products stay affordable. A cursory check suggests even yubico's product line are on the market for around $30/key. This is hardly expensive.

Perhaps you should look at the announcement. Of course webauthin is in the browsers.

Yes. You sound really confused right now. Perhaps you should take a step back and check your notes.

So my point stands

I don't think it does. It's quite obvious your claim about webauthm contrasts with reality. If you take the offer to check your notes, you can start here.

https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...

But something tells me no evidence in the world will sway your beliefs.

I think the universe of SPAs that should exist is far smaller than the universe of SPAs that does exist (...)

That's a pointless thing to say. Your personal opinion on how people should not use a technology weights nothing on a discussion on how the whole industry actually use said technology. For that to hold any value, first you would need to argue that you know better than the entire industry put together, which would be quite the claim. Occam's razor doesn't favor your statement.

If one already has an (non-React) SPA which is not already built following Redux then you're stuck with what you've got;

This is simply false and is outright wrong. This even goes against the most basic React+Redux guidelines. Dan Abramov, one of the creators of Redux, is quoted in Redux's FAQ:

would like to amend this: don't use Redux until you have problems with vanilla React.

https://redux.js.org/faq/general

it isn't really possible to take an existing SPA of any complexity and deciding to "make it use Redux"

Frankly, you sound as if you have absolutely zero experience with React. I know for a fact that a few flagship SPAs from a few companies, including some FANG webapps, do not use Redux.

...yes, Redux (not React) deserves to be #1,

This is a rather perplexing statement to make.

If anything, Redux only plays a role in adding syntactic sugar over React's support for reactive programming.

More importantly, the general guidelines are that you should only bother with Redux if your SPA is already considerably complex.

ReactJS has been a very mixed-bag...

This is a very confused statement to be made, specially after the last decade where React established itself as the de facto way of writing any and every SPA.

Is it yet another example of "there are only two kinds of languages: the ones people complain about and the ones nobody uses."

The WebAuthn thing could, in theory, make the browser remember your key so you don't have to pin every time you use it, but that only happens when Apple, Google and others implement this proposed standard. Right now, no browser can call it. Not Chrome, not Safari, not anything.

Wikipedia says that "WebAuthn is supported by Google Chrome, Mozilla Firefox, Microsoft Edge, Apple Safari[13] and Opera.[32]"

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

Here's a Chrome link published back in 2018

https://developer.chrome.com/docs/identity/webauthn

Here's a Chrome DevTools article on their support for WebAuthn

https://developer.chrome.com/docs/devtools/webauthn

Perhaps you should check your notes?.If you know something that everyone around you doesn't, please update wikipedia's article.

I see this as the same argument in old days where Harvard law school banned computer in favor of the typewriter

No. It's more like clueless students trying to pass off a screenshot of a Google search for original research.

What I would argue is knowing what topic to write is more important (...)

Except you don't. At most you are saving the output that everyone around you is more than able to type themselves, with the benefit of people being able to continue their own chat session.

Just call a spade a spade: spamming content that's way beyond your technical ability in a desperate attempt to generate engagement.

(...) but I'd wager that the majority of these papers is not complete slop (...)

That's a huge assumption, and one that goes against the whole notion of using LLMs to generate text. AI slop is by far the norm.

My opinion is: if it makes communicating research more effective, while not reducing the quality of the output substantially, I see no issue.

That's a big if. ArXiv is not peer reviewed and LLMs basically interpolate and extrapolate text, which makes them essentially fluff generators. Even in the most charitable interpretation, LLMs enable those with nothing to say to say nothing while meeting surface-level style guides.

I don't see it in grok or chatgpt launch threads.

There's some wilful ignorance in your comments. Elon Musk's businesses have been taking a colossal hit due to his role in the Trump administration and pushing fascism across the world. To say that grok, the very models that have been announced to be trained as "anti woke", as not being subjected to criticism, is beyond belief.

A lot of hypotheticals, conjecture, speculation, personal feels devoid of any facts.

No,not really. There is only one point: does Bun acknowledge that past contributors still hold copyright over the Rust rewrite?

This post still takes me almost an afternoon to finish, but without AI, it will take me much more time.

Why do you think people will bother reading something you didn't bothered to write?

Why does changing to Rust kill the project? I don't understand the point here.

I'm concerned that the complete rewrite in an entirely different language is not a sound technical decision and instead is a ploy to shed copyright claims from past contributors.

Now, based on comments from this thread, the formerly FLOSS project is somehow granting special access to a corporation that apparently is invested in going way out of their way to push implementations that consume the complete rewrite before the world has access to it.

I for one won't be touching Bun. This doesn't pass the smell test. It feels like a bait-and-switch in progress.

Really enjoying the picture of this user who logs into his router and decides that all unsolicited network traffic from the internet should go to his network camera. Absolute legend. God amongst men.

If that idea surprises you then you definitely need to touch grass. Even cloud computing engineers are surprised to see random internet requests hitting services,and here you are assuming that any regular consumer that just wants a security camera to work will somehow have deep understanding of networking and DevSecOps and trying to ridicule those who don't.

This underscores the principle that IoT devices should not be allowed to communicate over the public Internet.

TP-Link is a prominent maker of network hardware, including home and mesh routers.

Unless you're dumb enough to (...)

It sounds like you are blaming the user for providing data that a service can leak. That's like blaming a user for writing personal emails when faced with an email provider that leaks emails.

And then bisect fails because it finds one of the many commits that broke the test before the actual regression

And that's ok. You skip the commit and move on with your life.

Making small atomic commits as you go in the age of AI tends not to go great because it forces too much human in the loop in a lot of cases (...)

You seem confused. In the age of AI your ai code assistants already do task-specific commits. In fact, you can easily create a skill to have ai do that for you. It can even use git history split.

You see where this is going?

OP's advice is bad and lazy. You want to have a coherent commit history with isolated changes.

See my reply here https://news.ycombinator.com/item?id=48903456

How would you identify the commit that broke the test?

You're asking how to use bisect.

You start with a range of commits you picked. All that bisect does is help you search for a commit within that range that introduces a regression. The responsibility to specify which commits you cover is yours, not the tool.

And you can also use bisect by first figuring out the broken commit some other way (...)

Bisect exists to be a tool you can use to fix the problems you are facing.

It you are faced by problems you create for yourself and you are unwilling to work around the problems you are creating then there is no tool on earth that can help you.

I am convinced that very few know about git bisect, much less use it regularly.

Yes, unfortunately not all companies have a high hiring bar. Some

Isn't this solved if you squash the commits when merging the PR?

In theory, yes. Squashing is an extreme approach to merging fixup commits.

It also throws the baby out with the bathwater by removing individual commits that explain and clarify how and why some changes were introduced as part or a PR.

If your PRs are tiny and don't introduce major changes then squashing is ok. Instead, you should do the right thing and curate the set of commits featuring in your PR.

That sounds like it would break bisect

Nonsense. First off, you can pick the starting commit, and nothing forces you to pick the test one. Second, bisect is designed to tracks changes from good state to bad state based on your personal criteria of what good and bad is. This means that you are free to put up tests that make sense to you (i.e., all tests except the one that was added as a red test) and even not run a test at all.

Do you really care if someone forgot to format before committing?

Not OP but yes I definitely do. If you expect others to spend time reviewing your code, you are obligated to start off by reviewing it yourself. Posting a mess helps no one and makes code harder to audit.

The commits and history of how a PR was put together is no indicator of the quality of the PR or the thought process that led to it.

It is, because it means the person posting the PR didn't even bothered to review the changes they are forcing others to review.

Just clean after yourself before asking others to read your stuff.

What's up with the fix commits?

They shouldn't show up in the commit history. In a PR, you merge them in the commit that they actually fix. Otherwise when you use git blame to get the context of why a line of code was changed, all you see is a useless "fixup" message that is worse than having nothing.

Anyone can do better than a fixup commit. And doing metter means merging them into the actual commits that are fixed.