xatnys

Did you observe the model overthinking on practical tasks? While 3.8 does think a lot on xhigh I've found that it really depends on the task. On one-shot prompts that are usually the first to be posted during new releases it will tend to spend a lot more time thinking than doing. In other words the more open ended a problem space becomes, the more Qwen will tend to second-guess itself.

Conversely I've found that it can be as succinct as Muse Glimmer when it has a clear path forward. This can be either through well defined requirements or through unambiguous steps to take based on its own reasoning. While I do think it's fair to call out how much smaller model overthinks especially on one-shot prompts, in practice it hasn't led to an overall increase in time to task completion at least for what I've been using it for.

Is there a way to migrate a block list to a mute list? I used the block functionality for blocking promoted tweets.

I default to the Switch in many cases due to emulation not being compatible in ways that could be significant depending on the game. But if a game plays well on yuzu or ryujinx? Even setting aside better graphical fidelity, the massive increase in sound quality playing on a Steam Deck compared to the Switch makes it absolutely worth it. If I can get away with playing my games on better hardware, I will.

>refterm was ready to replace the terminal app

Considering Casey himself puts front and center the disclaimer that this is solely intended to be a reference and goes into as much detail in his videos I don't know where you got this from. I don't think anyone is under the illusion that this is could replace the actual terminal. It's just meant to show that there's a minimum level of performance to be expected for not a huge amount of effort (a couple weekend's worth) and there is no excuse for less.

This is only tangentially related but is anyone using Spring Cloud + Consul? Is the integration of the two in a good spot now?

Most major US banks currently support instant transactions up to a certain amount.

Check if your bank has an equivalent Zelle client; it's usually built into your banking frontend as a transfer or send money feature.

Other banks are also supported, but you'd have to register through the clearXchange network until your bank builds support directly.

While not particularly original, I would place this under 'thoughtfulness' / 'thoughtfully'. Code thoughtfully, but don't dive into premature optimization.

It all depends on the implementation. What you're describing is pretty common, particularly on blogs comment systems and YouTube.

This can likely be extended to only be utilized on part of a widget. If it's something like an ajax call you can easily add an option to cancel the request e.g. underneath a spinner.

For your report example in particular the service could be developed in such a way that the processing occurs independently of the user session. You can mix this in with an additional request which returns the actual progress of what has been calculated in the report such that whenever a user browses to that page, they can see just how much time there is to go before their report is generated.

Aside from the reality that a user won't always know their connection is slow / has slowed (particularly when it comes to bad routing between server and client), this is also typically used in cases where you are utilizing XHR.

Given that they're done in the background, the browser won't indicate them being made outside of dev tools. If they're asynchronous, again ideally they will take place as quickly as possible. This is unfortunately not something that can be relied upon.

Certainly, with web applications you would want the least amount of latency possible. This is a normal UX scenario -- as you indicated, there are factors which can simply be out of the hands of the application such as network connectivity.

In cases like that, indicating to the user that something is happening makes for a better experience than not doing anything, or in the worst case (which certainly shouldn't happen these days) blocking the user's browser.

Forcing a tie is an interesting approach, but daily double hunting is not new to the game at all. If you observe the way the contestants play, it becomes obvious who is playing with a strategy and who is just running down the categories. As for the ties, there's nothing wrong with it (honestly it's a good play), I only feel bad for those contestants who end up waiting longer as the queue becomes staggered.