For me, it really is a wonder drug. My blood test results were stellar when the drug worked for me. Unfortunately, with me, it either works and I get side effects, or it doesn't work at all. I feel minimal effects (and almost no weight loss) even on a 10mg dose.
Has anyone found the chip on AliExpress? I only get unrelated listings with that part number, but this is a pretty interesting chip I'd like to get a few of.
An alternative would be a supercapacitor and a voltage divider connected to the ADC pin of the microcontroller. When the 5V rail dies, the supercapacitor can hold 3.3V for a few seconds while you write everything to the EEPROM.
It's as if people have never had shipping itemized before.
The only reason aliexpress shopping is cheap is because the rest of the world foots the bill. Unless somebody has finally removed China's "Developing Country" status thats gotten them essentially free international parcel service for the best part of 100 years.
I buy small parts with "Choice" shipping on AliExpress sometimes, because it's cheap and [usually] quick and they take care of all of that pesky tariff and customs business in ways that never have an opportunity to surprise me.
For years now, the shipping process has worked like this for me: They gather it up on their end and send the stuff on a cargo plane to a sort that is at or near JFK airport in New York.
If the order includes things from several different sellers, then at some point they generally get combined into one bag.
From there, they just mail it -- using regular, domestic USPS service. It shows up in my mailbox on my porch in Ohio a few days later.
Although it certainly was a thing I've experienced in the past, at no point does the process I've described exploit the "Developing County" loophole. They just send things to the other side of the world (at their expense), and then pay the post office the same way as anyone else does to bring it to my door.
Yeah OK, but if I only want 5 pieces and I have to choose between $5 or $30, I'm not going to think about the geopolitical situation, I'm just going to get the cheaper one.
The obvious answer is to use a Raspberry Pi as a GPS-disciplined NTP server, of course. Place it near the window or fully outside, depending on GPS signal strength.
That gives you another weekend project, and you can reuse your DIY NTP wall clock!
That never quite solves the auto-timezone/DST issue that OP wants to have work, though, does it?
If I am interpreting their request correctly, they want a wall clock that knows where it is -- and also knows what localtime is in that position on the globe.
GPS (plus some hairy lookup tables) can accomplish that.
My current house, with low-E windows, aluminum siding, and a metal roof? It passionately hates everything about GPS.
But in more-typical (stick-framed, asphalt shingled, vinyl-sided, US-ish) houses? I haven't had any trouble with my very inexpensive u-blox (or perhaps clone) GPS board, a presumed-decent GPS antenna that we were throwing away at work, and dainty little [IIRC] u.FL to SMA adapter to connect the antenna with. (I put this all together just to play with making a GPS-backed, low-stratum NTP server -- which was a much more-rewarding process than it had any right to be.)
It was bizarrely good, in fact: While it certainly saw more birds and presumably had better accuracy when sitting in a window, I had real trouble getting it to cease to operate. It seemed to lock on well-enough to provide time and PPS until I put the antenna into a windowless closet.
That said: The antenna that came with this cheap receiver was trash -- at best, 1/10. It was hard to make it work even outdoors on a clear day. I eventually got sick of looking at that part and binned it.
Huh, I have the opposite experience, I love Zulip's UX. The fact that everything is a thread in a channel means I can quickly skip the threads I don't want, and I don't have to mark things as read in an all-or-nothing fashion. Slack doesn't let you do this, if you read a channel, it's now read, and you can't say "actually, keep this thread unread for later".
I understand that part but it makes it really difficult to peruse when joining a large instance. I have little to no idea what I'm even looking for, which actions are going to cause side effects others can see, etc.
that's the user-facing definition but the implementation distinction matters more.
"takes longer than you're willing to wait" describes the UX, not the architecture. the engineering question is: does the system actually free up the caller's compute/context to do other work, or is it just hiding a spinner?
nost agent frameworks i've worked with are the latter - the orchestrator is still holding the full conversation context in memory, burning tokens on keep-alive, and can't actually multiplex. real async means the agent's state gets serialized, the caller reclaims its resources, and resumption happens via event - same as the difference between setTimeout with a polling loop vs. actual async/await with an event loop.
IMO feels sorta like Simon Willison's definition of agents. "LLMs in a loop with a goal" feels super obvious, but not sure if I would have described it that way in hindsight
Maybe, but that's what I thought while reading the "what actually is async?" part of the post, so I don't think I got biased towards the answer by that point.
One nuance that helps: “async” in the turn-based-telephone sense (you ask, it answers, you wait) is only one way agents can run.
Another is many turns inside a single LLM call — multiple agents (or voices) iterating and communicating dozens or hundreds of times in one epoch, with no API round-trips between them.
That’s “speed of light” vs “carrier pigeon”: no serialization across the boundary until you’re done. We wrote this up here: Speed of Light – MOOLLM (the README has the carrier-pigeon analogy and a 33-turn-in-one-call example).
Speed of Light vs Carrier Pigeon:
The fundamental architectural divide in AI agent systems.
The Core Insight: There are two ways to coordinate multiple AI agents:
Carrier Pigeon
Where agents interact: between LLM calls
Latency: 500 ms+ per hop
Precision: degrades each hop
Cost: high (re-tokenize everything)
Speed of Light
Where agents interact: during one LLM call
Latency: instant
Precision: perfect
Cost: low (one call)
MCP = Carrier Pigeon
Each tool call:
stop generation →
wait for external response →
start a new completion
N tool calls ⇒ N round-trips
MOOLLM Skills and agents can run at the Speed of Light. Once loaded into context, skills iterate, recurse, compose, and simulate multiple agents — all within a single generation. No stopping. No serialization.
The artifacts weren't a conscious design decision, they were a constraint. We don't know whether the designers would have chosen to keep them or not, if they had the choice.
You say that, but it was quite common to "allow" a bit of aliasing in sampling back when we had very limited equipment, to introduce a bit of "sparkle" into percussive sounds that would otherwise be lost by low sampling rates.
Given its spectral complexity can you even tell if a hihat sample is aliased?
The idea that sound designers on old games were totally siloed and ignorant of how their compositions would sound on final consumer hardware is completely wrong. Most of these composers were programmers themselves and knew exactly how to get the final hardware to make the sounds they wanted, even when they composed using more advanced tech.
Programmers using devkits (more powerful than the consumer hardware) likewise.
I don't understand what you mean. Nobody said they didn't know how their compositions would sound, my argument is that at least some of these composers would have chosen the more advanced interpolation method, if it were available.
I guess it's hard to stop my originalist tendencies from boiling over into other topics...
What you're saying to me is like someone saying, well, if the piano had more octaves then existing compositions would have been better. But those pieces were composed with the current amount of octaves in mind in the first place...
Maybe there's an analogue with the harpsichord-to-piano transition, but I'm not knowledgeable enough about that yet.
Haha, my first gut reaction to reading your second paragraph was "No, it'd be better to compare it to compositions written for harpsichord and played on piano".
I guess history has shown that most composers (and listeners) preferred the piano sound over the harpsichord sound the majority of the time.
That may be true, but the sound designers were still making the best of what they had. They could probably imagine how the same composition would sound better.
When you play e.g. Gamecube games in an emulator, do you run them in 480p or do you render at a higher resolution? The former is clearly what the designers were targeting, but I think there’s rarely any benefit to eschewing higher resolutions. It just looks even better.
Cheap electronics are just the feed stock, the basis function for your new creation. Why start with raw matter when you can get fully formed matter for less.
reply