FridgeSeal

MS Authenticator used to dispense codes on the watch app, but since about ~2022 MS decided that they would disable this feature.

No reason was ever given, especially as they actively removed an otherwise working feature, so I can only assume “user hostility” and/or “classic incompetence”. Probably both, being Microsoft.

Because they don’t want to sign up for 10 different providers and subscriptions/etc, especially if some models are just going to receive light, or rare usage?

Where do you work?

Mostly so that I can know to never apply, because that application process sounds awful and degrading.

Yeah but instead of “hostile OS, hostile applications, subpar applications”, you can reduce it to just “occasionally subpar applications”.

Getting off a hostile OS should be such an obvious choice we oughtn’t need to specify it, but here we are.

And one of them is always something just completely out of scope and the other is something obvious it missed.

“One thing worth your attention, if you were to detonate a pipe bomb in your house, it would have a negative effect on your living room”.

Which would be fine, but the parents also just smeared tomato sauce over the walls too, so let’s not get too ahead of ourselves.

Because new stuff instantly makes anything prior bad and incapable and garbage of course! Did you forget the hype-machine speaking notes??? /s

Human-somewhere-nearish-the-loop!

They were VC-backed, and had some kind of sign-up/account system for the early invites.

This smells an awful like a post-hoc justification of why you can’t answer it yourself.

If you _could_ do that and hand the information to Claude, you could also just…give the person that information directly, and avoid wasting their time and the tokens.

Management/exec have also decided that this is a desirable form of “stupid and lazy” and are actively encouraging it, and discouraging the “old way”.

Just ask Claude to fix it, what’s the problem??????? /s

The managers, aren’t on the hook for actually understanding and delivering the work, or fixing the system a week later when the vagaries of their wand-waving request come home to roost though.

Ooh look! “The x is priced in”! My favourite financial thought terminating cliche!

No need to worry or discuss further, it’s all priced in! Everything’s totally fine!!

Let’s not forget to count all the people who use a MS office product at work, and are therefore opted into counting for copilot numbers, which almost _certainly_ counts towards ChatGPT numbers by default!

If exploitation is the game, ad-tech companies will find a way!

Talaas have done this with a llama 3 model. Runs at like, 16k/tokens a second oror something obscene. Very little power draw too.

Doesn’t need hbm or lots of memory, because the hardware can just forward the data straight to the next layer and you don’t need to round trip through memory.

They claim to be working on an approach to make the underlying hardware a bit more reusable between models.

This reads an awful lot like post-how justification of poor business practices.

It’s got a bit of”uhhmm actually, poor management and high turnover is good actually” vibes, which is then (over)extended to a kind of carte-Blanche justification of “why using kms and having no idea of what’s going on” is good-and-desireable.

Which is like, certainly a take, and I can think of at least one “technical skills hating” exec from a past life who’d read this and foam at the mouth to feel justified in their decisions to try and throw all engineering practices out with the proverbial bath water.

It sounds like you’ve got a super interesting stack going on there, evidently with a large performance/latency focus.

May (haha) I ask what this is in service of? I’m somewhat a fan of the thread-per-core model, so I’m curious as to what you’re doing with it.

> Increasing threads beyond system's hardware cores/threads resulted only in marginal gains of a couple of milliseconds worth of differences on huge workload with large increase in memory

Careful, if you say that too loudly, the "get rid of async just spawn more threads!!!!!" people will come out of the woodwork to yell at you about how _all_ async is a lie and we should instead pretend none of it exists and just spawn more threads.

> but if it falls prey to these pitfalls, it would make me pause before adopting it.

This issue isn't really a Tokio concern, it's pretty straightforward to write Rust code that has back pressure mechanisms. The "it's not reasonable" in my mind implies that if someone goes and _does that_ then there's not much a library can do to restrain the developer.

This reads an awful lot like the prompter had a semi-confusing time with some async, and had their favourite model write an upset blog post about it.

I don't think these systems are perfect, nor are they fit for every use-case, but some of the complaints ring a bit hollow.

> fetching a database record over the network, then immediately crunching the data. But what happens when that data crunching involves parsing a 10MB JSON payload

Mixing IO-sensitive code and blocking code causes issues, who knew? I'm not quite sure how these libraries are supposed to magically _save_ you from this?

> When these latency spikes occur, the answer is always the same: separate your runtimes.

Well yeah. "Why doesn't my daily-driver cut sick lap times around the Nurburgring?" If you want to run blocking, non-interleaved code, don't do it in an executor expecting small, interleaved, non-blocking tasks. The docs for Tokio even mention this, and provide a number of worked examples of integrating/bridging sync and async code.

> If a developer must manually partition I/O and compute, strictly police the boundaries to prevent deadlocks, and ferry data between two different runtimes with two different mental models, the async abstraction has failed.

Not necessarily. If I'm chasing a performance target, and the tool gets me 80-90% of the way there, to the point where my next task is optimising layout and caching, I call that a win. That's performance ground we'd have to address at some point if we want to go faster, so getting there easily means: - those people who don't need to go faster because their perf requirements are met are happy - those people who need to go further get to skip the intervening work, and go straight to these optimisations.

Edit: also wanted to make a point about the "memory blowup" the author mentions. It's entirely possible to do the _same_ load-shedding the author wants in Rust/Tokio/Monoio/etc, this is again, just a matter of building your application in a way that uses, and communicates back-pressure. I gather that they appear to want something which is a bit more opinionated and "batteries included" as far as functionality goes, which is totally fine-and-cool, but calling Tokio + Rayon _bad_ because they explicitly don't do this is a bit of a miss.

That is indeed, the joke.

> don’t understand why anyone thinks management of any kind was involved in this at all

Because it’s marketing gold? Any marketer worth their salt would be super keen to get their claws into a project like this.

Anthropic and friends are in then business of selling LLM’s. This is a demonstration of LLM capability, they’d be foolish to not even try to cash in on it.

Plenty of companies, very much _want_ this.

I agree, that work in these places is likely short lived, if for no other reason than working in them is awful and demoralising. My point is, that these places exist, and have such a hard-on for “oh my god, AI!!!1!1!” that putting in extra effort there, is a waste of your own energy.

> I just don't care anymore because it's not my responsibility or my code at all at that point

Yep, 100%.

Business has made it clear they don’t care, so there’s no point in burning one’s energy. Throw the whole thing on auto, check out, and go do something else during the day.

Amusing that you think businesses still have QA teams.

> If you encounter something that’s not an int, that could be a signal you have a bug in your writers

Which, is something you could have caught before it got written at all if you had your db enforcing your types.

Because how it’s made and functions is useful information for dealing with it when they’re trying to attack you?

I give coastal piracy about 3-weeks to figure out how to commandeer unmanned cargo ships. I bet they’d be ecstatic.