It might meaningfully change the business model of LLM businesses. Becomes seemingly much harder to universally charge $30/mo subscriptions when the user is bringing their own API key.
Right. IIRC, the acquiring bank would send an authorisation advice to the issuer when it comes back online. An auth advice is like notice that a payment happened, the issuer doesn’t really get a say in rejecting it (as it does for an authorisation). For the most part, anyway.
If that transaction brings the customer into a negative balance, it’d be between the bank and customer to figure that out. Especially if the customer has no overdraft facility and isn’t supposed to be able to go negative, and isn’t able to easily recover the payment, or the customer is considered vulnerable, then the bank will often just swallow the loss.
I’d agree. The biggest exception I can think of is X, which post-Musk has plans to reduce/remove ads. Though I don’t know how much this tanked their ad revenue and whether it was worth it.
or not like the recent FB AR glasses. if your live demo doesn't work in rehearsal, there's a good chance it's not going to work during the actual presentation. there's a reason the phrase "demo hell" is well understood.
But the problem is that the product is buggy. The question then is "can you fix those bugs before products ship."
I'm not sure what the problem is here. Customers don't want buggy products. Live demos are more informative to users who can't tell what the actual experience will be like vs what the envisioned experience is.
I'm sorry, but as a customer I don't care what's in a developer's dreams, I care what I can buy.
eg: if you want distributed systems, esp Java-style, https://www.martinfowler.com is a pretty handy reference. (similar for other areas of SWE).
It’s nice to have a single resource that documents a bunch of non-obvious but still-generally-accepted engineering practices relevant to a domain. It’s of course an opinion, but is reasonably uncontroversial. Or at least, you won’t go too wrong while you develop your own taste in said domain.
Graphite seems cool, it’s just unfortunately quite expensive and sometimes hard to convince procurement/etc to invest in when it has a noticeable cost involved.
So I’m really hoping something like Graphite becomes open-source, or integrated into GitHub.
I don't know enough about networking as I should, so to plug for my gap in knowledge, I generally prefer to use more comprehensible (to me) forms of security. And a feature like this:
> Speaking of SSH, Tailscale has special support for it whereby it handles any incoming connection to port 22 from the Tailscale network, and deals with authentication itself. No public keys or passwords: if you’re logged into Tailscale you can be logged into the machine.
kinda worries me (given also IP spoofing is possible?), compared to SSH keys whose mechanism is more obvious and thus easier to trust.
I definitely like the idea of Tailscale as an extra layer of protection, but I'm not sure I'd loosen existing protections while using it, whereas many Tailscale articles often present it as a panacea for internal-network-over-the-internet security. Are my concerns misplaced?
> kinda worries me (given also IP spoofing is possible?),
It's not, Tailscale authenticates incoming connections. (Note that we're not talking a regular SSH connection to the server's public IP here. You'd connect to the server's SSH daemon through Tailscale.)
