I'm curious: If someone wanted to serve models off hardware/silicon directly (like Cerebras or Taalas, and soon Google I think) rather than GPUs, would these parameters still be adjustable at request time? Or would they have to decide that before the model can even start serving and it would be locked in until they reload it (which would make it briefly unavailable)?
I'd expect that sampling would happen in software. Probably the hardware system would output a vector of probabilities over the tokenspace, just as the nets do when run in software.
I don't know though and am not aware of any docs going into detail here. That being said, sampling is really cheap. So implementing it in hardware wouldn't be worth it.
These days, browsers absurdly try things like adding www. if you don't have it, and there's no open port. Same for http -> https.
This is doubly an issue, as browsers think hiding the http and www is super cool.
So in modern times, you'd never know if the non www was borked or not. It'd just seem slower, especially with a packet drop.
Ideally, you'd want to know there's an issue, not mask it. For example, by updating your bookmark, instead of saying "this site is slow every time".
I wonder of we'll just stop selling forks, because expecting users to learn a tool is verboden. In truth, it is the ridiculous change to tools for no reason which is the issue. Redesigning the UI almost yearly, moving menu items, changing menu item names, and other absurdities. Apparently this is all sensible, whilst expecting the user to know https vs http, and www is absolutely bonkers, and we must help and protect them from this horrible weight of knowledge.
It’s been a very long time, but as I recall MS recommendations for AD domains and dns collisions changed multiple times. Used to be real problems if you had overlap.
A cash advance is taking physical cash out with your credit card at an ATM or bank teller. Making an online purchase (which depositing money into your Kalshi account is) is therefore not a cash advance.
There are many kinds of "cash advance". You can't buy lottery tickets on a credit card (or in jurisdictions where you can, it's a cash advance). Credit cards also treat things such as buying dollar coins online from the US Mint different from a normal transaction.
I saw this for the first time in NYC at a dispensary, i’ve never seen a payment terminal charge me $4.75 for an atm transaction fee but it was pretty smooth.
In Australia any sort of gambling payment on a credit card is treated as a cash advance. If you use PayPal on top of your credit card, the credit card company still manages to introspect it and apply a cash advance fee.
But if you somehow have a 100% correct prediction you are now "insider trading" and that is not allowed because all gambling.. ahem, all betting... hmm... All predicting much be "fair" and "random" and definitely not too good.
Not necessarily, I mean if you buy a in-game item or currency that wouldn't be a cash advance so with this they could just say you bought $20 worth of credits and since you're buying credits that could be considered a good.
This is not gambling in the legal sense (gambling is not even allowed in my state, and yet here I am using Kalshi, in case you wanted to argue that), which is why my transaction was classified as Professional Services and, for the nth time, NOT a cash advance.
What if the site allows you to purchase a digital asset such as a CS2 skin which you can then immediately sell back to them at the same price you to get credits in your account to gamble?
If done at scale, you will get complaints/chargebacks that will trigger an audit followed by fines and/or account closure. Banks and underwriters have standard procedures in place to catch this.
I'm trying to understand which part exactly is fraud? If this site offered a legitimate marketplace for these items as well as gambling then in certain jurisdictions of course that could be illegal (due to the gambling aspect) but where does the fraud come in exactly?
Depending on circumstances, many activities under the same banner of analogy are actually fraud as well. I suggest talking to a lawyer before making any plans. Fraud is more about intent to circumvent, and chaining together individually-legal activities is the most common path to a fraud conviction.
It's not a cash advance. I funded my Kalshi account using a Capital One credit card. Not only was it not classified a cash advance, I got 1.5% back as is standard on this card.
I really appreciate all of the colourful feedback, but as I have said, this is not a cash advance. It was classified as Professional Services by Capital One and I received 1.5% cash back as is standard with the credit card I used.
The issue stems from the fact that people believe prediction markets are gambling. Prediction markets are financial derivatives regulated by the CFTC. This definition is not something I am trying to defend, I am simply accepting the current legal definition to explain why funding your Kalshi account is not considered a cash advance. Gambling is not even allowed in my state, yet Kalshi is permitted. Legally, Kalshi is not gambling as of the current legislation. That is why, for the nth time, funding your Kalshi account is NOT considered a cash advance.
People should do a little bit of research before blindly downvoting, or maybe even try it for themselves.
The visualiser seems to be quite naive with what it defines as a token. I don't think a token is an entire word as often as the demo shows, and when it gets to the `def estimate_tokens` method, the entire `# Rough heuristic: ~1 token per 4 chars of English` comment is printed all at once as one token, which is certainly not accurate.
This is not a realistic replay of what a common LLM might actually print out - it's entirely fabricated. But for the purpose of estimating the feel of tokens per second, I suppose it's good enough.
I built something similar awhile back [1] and used OpenAI’s tokenizer playground [2] to recalculate tokens on a giant block of lorem ipsum text. I feel like this gives a much more accurate representation.
The people that's a problem for don't understand this fact. Of the ones that do, there's upper management and/or shareholder pressure for profits now. It's a can that infinitely gets kicked down the road until they reach a dead end.
I see this take all the time, but hiring a junior/intern has never been great ROI, so I hear. Why did we ever do it in the past? Its not like it was ever likely that hiring a junior means getting an employee for life. Could it be that the economic and shareholder pressures are requiring this rather than it being a logical thing?
Anecdotal counterpoint, the best teams I've been on have always had a good mix of a couple of really senior/decent intermediate people and a few either totally fresh grads or juniors (at the beginning of the project). Those fresh people have a good chance of becoming pretty formidable pretty quickly with the right mentoring, and without them seniors have a tendency to just remain experts on whatever tech stack they're familiar with but not think out of the box.
Hiring a mediocre senior is much worse than hiring a grad because they will never get any better, and it's very hard to know at hiring time that they're mediocre.
I'd also add that top-heavy engineering organizations are sometimes incapable of delivering anything useful because everyone wants to work on the hard problems, establish the frameworks, define the processes, and so on, and no one wants to operate the damn business. It's good to have a mix of perspectives in a team.
Fully agree actually. Not sure its a counterpoint at all really, but its a great point. My comment wasn't intended to be "juniors were never worth it", but instead "juniors WERE worth it before but not because they produced amazing ROI themselves, why does the introduction of an LLM change that?" I'm solidly against the narrative that now all of a sudden juniors aren't worth hiring anymore because a senior with an LLM = 100x engineer.
They're making the bet that seniors won't be needed by then. I think it's a bad bet, but it makes sense to follow through if 40% of the economy is already being occupied by this tech.
Then pay will go up again for those mid-level developers who still remain, and companies will again overhire and overtrain like we saw during COVID years. “We won’t have any seniors in ten years!!1!” is a handwringy problem that self solves by the free market.
Does this help with DuckDB concurrency? My main gripe with DuckDB is that you can't write to it from multiple processes at the same time. If you open the database in write mode with one process, you cannot modify it at all from another process without the first process completely releasing it. In fact, you cannot even read from it from another process in this scenario.
So if you typically use a file-backed DuckDB database in one process and want to quickly modify something in that database using the DuckDB CLI (like you might connect SequelPro or DBeaver to make changes to a DB while your main application is 'using' it), then it complains that it's locked by another process and doesn't let you connect to it at all.
This is unlike SQLite, which supports and handles this in a thread-safe manner out of the box. I know it's DuckDB's explicit design decision[0], but it would be amazing if DuckDB could behave more like SQLite when it comes to this sort of thing. DuckDB has incredible quality-of-life improvements with many extra types and functions supported, not to mention all the SQL dialect enhancements allowing you to type much more concise SQL (they call it "Friendly SQL"), which executes super efficiently too.
Hi, DuckDB DevRel here. To have concurrent read-write access to a database, you can use our DuckLake lakehouse format and coordinate concurrent access through a shared Postgres catalog. We released v1.0 yesterday: https://ducklake.select/2026/04/13/ducklake-10/
I updated your reference [0] with this information.
Regarding documentation, I think the DuckLake docs would benefit from a relatively simple “When should I consider using DuckLake?” type FAQ entry. You have sections for what, how, and why, essentially, and a few simple use cases and/or case studies could help provide the aha moment to people in data jobs who are inundated with marketing from other companies. It would help folks like me understand under which circumstances I would stand to benefit most from using DuckLake.
DuckDB devrel here. You are right. This was in the FAQ but I also added it to the DuckLake documentation's main page at https://ducklake.select/docs/stable/
My employer is in the midst of migrating petabytes of data from Snowflake to DataBricks. They’re sold on the “all in one” nature of the platform and believe they’ll save significant money through a contract locking them into DataBricks running on Azure. It is a wildly disruptive process in an environment where the “Snowflake police” (as we call them) have been hounding everybody to reduce credit usage. Now the IT platform team is trying to explain units of work to non-technical VPs, for example, and there’s mass confusion. All signs point to them ending up in the same situation with expensive DataBricks bills, vendor lock in, and a future migration to try to reduce costs.
I guess what I was trying to say is that DuckLake isn’t even a blip on their radar. Should it be? Could you explain it to a non-technical marketing VP as part of a cost savings measure? What’s the DuckLake equivalent to a Unit of Work on DataBricks or a Snowflake Warehouse? If I needed to join multiple tables with billions of rows, where does the compute happen in DuckLake? Can you run your own cluster like with Clickhouse or StarRocks? How does it scale horizontally with storage and compute? How do I update it? What if there’s a security flaw? How well does it stand up to 500 people querying it simultaneously and what type of setup would I need to achieve that?
The PMs that manage the IT platform team aren’t necessarily deeply familiar with all of the technical details. A compelling introduction to DuckLake would provide the answer to some of these questions in a way that the VPs or PMs could digest it easily while providing the technical details the data workers require. For better or worse, “data lakehouse” and data warehouse and data lake all are industry jargon that is pretty impenetrable to people who don’t spend a lot of time working with the tools but who cut checks and make decisions.
DuckLake is great for the lakehouse layer and it's what we use in production. But there's a gap and thats what I'm trying to address with OpenDuck. DuckLake do solve concurrent access at the lakehouse/catalog level and table management.
But the moment you need to fall back to DuckDB's own compute for things DuckLake doesn't support yet, you're back to a single .duckdb file with exclusive locking. One process writes, nobody else reads.
OpenDuck sits at a different layer. It intercepts DuckDB's file I/O and replaces it with a differential storage engine which is append-only layers with snapshot isolation.
Yes, this is actually one of the core problems OpenDuck's architecture addresses.
The short version: OpenDuck interposes a differential storage layer between DuckDB and the underlying file. DuckDB still sees a normal file (via FUSE on Linux or an in-process FileSystem on any platform), but underneath, writes go to append-only layers and reads are resolved by overlaying those layers newest-first. Sealing a layer creates an immutable snapshot.
This gives you:
Many concurrent readers: each reader opens a snapshot, which is a frozen, consistent view of the database. They don't touch the writer's active layer at all. No locks contended.
One serialized write path: multiple clients can submit writes, but they're ordered through a single gateway/primary rather than racing on the same file. This is intentional: DuckDB's storage engine was never designed for multi-process byte-level writes, and pretending otherwise leads to corruption. Instead, OpenDuck serializes mutations at a higher level and gives you safe concurrency via snapshots.
So for your specific scenario — one process writing while you want to quickly inspect or query the DB from the CLI — you'd be able to open a read-only snapshot mount (or attach with ?snapshot=<uuid>) from a second process and query freely. The writer keeps going, new snapshots appear as checkpoints seal, and readers can pick up the latest snapshot whenever they're ready.
It's not unconstrained multi-writer OLTP (that's an explicit non-goal), but it does solve the "I literally cannot even read the database while another process has it open" problem that makes DuckDB painful in practice.
Nice app! I see that the page title says "client" and there's the Vite favicon still, which you might want to fix :)
I also think having a dropdown for the address search is somewhat expected these days, but is lacking here. That might be on purpose or due to a technical limitation, but just thought I'd mention.
That is not correct at all. How did you arrive at that conclusion?
GPS has its own independent timescale called GPS Time. GPS Time is generated and maintained by Atomic clocks onboard the GPS satellites (cesium and rubidium).
It has its own timescale, but that still traces back to NIST.
In particular, the atomic clocks on board the GPS satellites are not sufficient to maintain a time standard because of relativistic variations and Doppler effects, both of which can be corrected, but only if the exact orbit is known to within exceeding tight tolerances. Those orbital elements are created by reference to NIST. Essentially, the satellite motions are computed using inverse GPS and then we use normal GPS based on those values.
> It has its own timescale, but that still traces back to NIST.
GPS gets its time from the US Naval Observatory:
> Former USNO director Gernot M. R. Winkler initiated the "Master clock" service that the USNO still operates,[29][30] and which provides precise time to the GPS satellite constellation run by the United States Space Force. The alternate Master Clock time service continues to operate at Schriever Space Force Base in Colorado.
> As a matter of policy, the U.S. Naval Observatory timescale, UTC(USNO), is kept within a close but unspecified tolerance of the international atomic timescale published by the Bureau International des Poids et Mesures (International Bureau of Weights and Measures [BIPM]) in Sevres, France. The world's timing centers, including USNO, submit their clock measurements to BIPM, which then uses them to compute a free-running (unsteered) mean timescale (Echelle Atomique Libre [EAL]). BIPM then applies frequency corrections ("steers") to EAL, based on measurements from primary frequency standards and intended to keep the International System's basic unit of time, the second, constant. The result of these corrections is another timescale, TAI (Temps Atomique International or International Atomic Time). The addition of leap seconds to TAI produces UTC. The world's timing centers have agreed to keep their real-time timescales closely synchronized ("coordinated") with UTC. Hence, all these atomic timescales are called Coordinated Universal Time (UTC), of which USNO's version is UTC(USNO).
The two organizations do seem to keep an eye on each other:
> The United States Naval Observatory (USNO) and the National Institute of Standards and Technology (NIST) make regular comparisons of their respective time scales. These comparisons are made using GPS common-view measurements from up to approximately 10 GPS satellites. The table below lists recent differences between the two time scales.
I think GP might’ve been referring to the part of Jeff’s post that references GPS, which I think may be a slight misunderstanding of the NIST email (saying “people using NIST + GPS for time transfer failed over to other sites” rather than “GPS failed over to another site”).
The GPS satellite clocks are steered to the US Naval Observatory’s UTC as opposed to NIST’s, and GPS fails over to the USNO’s Alternate Master Clock [0] in Colorado.
I find this stuff really interesting, so if anyone's curious, here's a few more tidbits:
GPS system time is currently 18s ahead of UTC since it doesn't take UTC's leap seconds into account [0]
This (old) paper from USNO [1] goes into more detail about how GPS time is related to USNO's realization of UTC, as well as talking a bit about how TAI is determined (in hindsight! - by collecting data from clocks around the world and then processing it).
> If those other applications use their own local GPS clocks, what is the significance of NIST (and the 5μs inaccuracy) in their scenario?
Verification and traceability is one reason: it's all very well to claim you're with-in ±x seconds, but your logs may have to say how close you are to the 'legal reality' that is the official time of NIST.
NIST may also send out time via 'private fibre' for certain purposes:
