herpderperator

If they want to airgap a model, then do it properly... exposing any aspect of the Internet whether via a DNS resolver or not, is not actually blocking Internet access.

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)?

https://govt.nz isn't a thing, but https://www.govt.nz is.

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.

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.

Prediction market aren't one of them. I checked my credit card statement and the transaction was classified as Professional Services.

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.

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.

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.

If you eliminate juniors over the next few years, there will be no seniors for the future when the current seniors retire.

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.

[0] https://duckdb.org/docs/current/connect/concurrency

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.

This sounds like swap needing to be swapped in and then released. Check your memory usage.

If those other applications use their own local GPS clocks, what is the significance of NIST (and the 5μs inaccuracy) in their scenario?

Can someone explain exactly what's happening here? https://github.com/nadimkobeissi/16iax10h-linux-sound-saga/i...

It seems like there's a lot of personal information being asked for / thrown around... including a debit/credit card number?

Is there no better way to handle the bounty payment?

I'm aware that the public IP changes when a phone (on which one hardly has much control over how things run anyway), switches from cellular to a WiFI network.

Your comments are more practical (and maybe aimed at a layman's use of Starlink) but I am talking about the theory of Starlink supposedly interrupting a perfectly-working connection in order to change your IP, which interrupts everything, by design of TCP/conntrack. Whether that operation is fatal or not due to retries or whatever else is not my point at all.

Also, ISPs at home don't randomly disconnect you to give you a new IP. They may give you a new IP when you disconnect and reconnect for other reasons, but they should never dump your connection on purpose just to give you a new IP for no reason. That's not good design at all, hence the question about how Starlink handles wanting to give you a new IP.

That would cause your active connections to break because the source IP changed entirely. Are you sure the IP changes abruptly, or they keep it for as long as the session is live? Though keeping the original IP would mean that, for example, if you are sailing around the world, you'd start getting worse and worse latency as all your data continues going to the original ground station which may be on the other side of the world at that point.

An interesting problem - I wonder what they truly do here. I suppose people expect interruptions with Starlink so doing an IP swap wouldn't be all that different to losing service due to obstruction for a few minutes.

Or, you know, just Gemini 2.6 Flash. I don't recall the 2.5 version having a date associated with it when it came out, though maybe they are using dates now. In marketing, at least, it's always known as Gemini 2.5 Flash/Pro.

Serious question: If it's an improved 2.5 model, why don't they call it version 2.6? Seems annoying to have to remember if you're using the old 2.5 or the new 2.5. Kind of like when Apple released the third-gen iPad many years ago and simply called it the "new iPad" without a number.

Reminds me of Dragon Drop... https://www.youtube.com/watch?v=DCu1G2rxj5c

Have they fixed the ability to easily transfer your existing Android data to the new Android phone? I find that every time I upgrade, despite choosing the options to transfer apps/settings, that 90% of the apps I open just greet me with the login screen and I have to set everything up completely from scratch. I remember maybe a handful of apps, I think one was Uber, that were able to transfer everything including the login session. That was truly magic. That's how it should be for all apps. I understand banks might have special security requirements and I already know for Google Wallet, your cards need to be reactivated even if they transfer over, but most apps are not banks.

For the sake of understanding, can you explain why putting CloudFront in front of the buckets helps?

When Google said GCP is "down", did it affect entire availability zones within a region? For people who designed redundant infrastructure, did your backup AZs/regions keep your systems online?

If the requirement is to check uniqueness, what assumptions could possibly cause a bug? In this case, why does it matter if the uniqueness is tested with a nested for loop or with a map? There are many identical ways to check uniqueness, some being faster than others.

phpMyAdmin was (is?) such a great tool and really got me into SQL/MySQL over a decade ago. Not to mention the whole PHP stack was so fun to use and let you iterate quickly and just build stuff with an immediate feedback loop - just reload the page and your updated server-side code is executed.

People can always "just."

If you read the article, no.

Can someone explain to me how this is? It's a company HQ'd in New York, but it's not allowed to do business in the very country it's HQ'd in? What am I missing?

No CPU gets slow after any amount of years. That's not how it works. I think what you're trying to say is: Software gets more resource-intensive.

Sorry to hear. I didn't have that experinece; it's been pleasant for me (there was a billing snafu while they changed their plan structure but it was resolved with a support email) and their monitoring has been very reliable since I signed up a year ago. Their service also seems to be better (4 checks/locations vs Uptrend's 2.)

Anyway, tl;dr is I never had an issue that resulted in not getting alerted about something that I needed to be alerted about, which, above all else, is the point of their offering.