enginous

One caveat to alerts (and automatically acting on alerts) is that there are delays[0] between costs being incurred and alerted. I can't find a Google source for what the delay is, but a source online say it could be "24 hours [to] a few days."[1]

This has been a major reason why I reach for OpenAI models before Gemini, but also why I'd rather use services like RunPod for training jobs. For a small boostrapped company like mine, it feels terrifyingly easy to rack up a company-ending AI bill.

The cloud companies try to limit these accidents through cranking your quotas down to nothing, but this also means that my small company can't just whip up 8xH100 easily without major ceremony, and I have routinely been rejected the GPUs quotas I needed for projects.

Accidentally leaving that kind of node on for the 24 hours that it might take to get an alert would rack up a $2,000+ bill, compared to $500 on RunPod, which will also stop the instance when you run out of money.

I've loved working with major cloud providers at growing VC-funded startups that have credits, TAMs and bigger budgets for errors. But hyperscalers are fairly difficult for a pre-scale bootstrapped business, and arguably not designed or optimized for it.

[0] https://docs.cloud.google.com/billing/docs/how-to/disable-bi... [1] https://support.terra.bio/hc/en-us/articles/360057589931-How...

I did just manage to dig up a source that says these things are somewhat implemented in iOS 18 with illustrative screenshots rather than actuals, and it seems to be implemented but currently janky:

- On iOS, rich cards have a message length limit of 144 characters. (Implies this is not a limitation on Android.)

- On iOS, multi-CTA might fold some of the options away. So you might give 4 options and it renders 2 options and makes you use a drop-down for the others.

- On iOS, carousels display as cards, which might not be as obvious to interact with.

https://www.infobip.com/blog/apple-rcs

Potentially improved in iOS 26. It's a little hard to work out the state of this, and of course not trivial to test without joining some kind of partner ecosystem.

I'm pretty unclear about how the experience they showcase in the video would work on iOS. Maybe Android has APIs for this, but on iOS it looks like RCS just supports green-bubble messages, links and files/multimedia. But in the demo they show multi-choice cards, carousels, cards with buttons, and reply auto-suggestions.

Also, someone correct me if I'm wrong, but it also looks like this needs to be agent-initiated, ie. you can't add a "Text us" button that will take you to this experience. (But you could capture a phone number, and text them _iff_ they have RCS available and enabled.)

Overall, seems questionable whether this is worth integrating if the experience is so fractured across platforms and many people might not even have RCS. The concept of a platform for rich messaging across platforms sounds good though.

This pattern of the virtual DOM has some parallels with functional programming. At first look, using functional programming it looks like you're sacrificing the performance that you gain from mutations -- which to some extent is true. But when you look deeper, you'll find that the data structures for functional programming languages have been adapted to work in a very performant way with functional programming patterns.

In the same way, when you look closer at the virtual DOM model, you'll find that you can optimize the usage very well. For example, when you use React with immutable data structures (e.g., Immutable JS), deep equality comparisons can be done very quickly to reduce renders to the minimum subtree required, and to issue the renders for a given change in a batch operation.

With React, you often end up with even faster code than using manual DOM manipulations. Of course, your performance will vary depending on how you implement your code. Depending on which model you're using, and how you program, you may end up with a faster or slower product with either methodology.

But at the end of the day, the performance gain from running code using state mutations just doesn't seem worth the effort of having a significantly harder time reasoning about the code, and having to deal with the challenges of scaling a project where the complexity grows much faster with each line of logic.

And my feeling is that due to the time invested in managing a more complex project that deals with mutations, the "performance per engineering hour" gained for projects using a virtual DOM is more favorable for many projects.

So, it seems that the change for production apps is that you can now somehow commit to a monthly price for dynos and get a discount.

  1X – $25/month compared to $36.5/month (by the hour).
  2X – $50/month compared to $73/month (by the hour).
  PX – $500/month compared to $584/month (by the hour).

I'm also interested in what has changed. The dyno-hour prices of $0.05, $0.10, $0.80 for 1X, 2X and PX, respectively, seem the same as before.

I think the stuff React is doing is impressively simple and non-magical. Although I haven't used React yet, I wouldn't be surprised if these ideas make for code that's relatively easy to reuse and reason about.

The format of the post is also quite nice; a few short points with illustrations and a clear takeaway.

Also, his idea of increasing taxes will mean that even if his statement were true ("[if] people only bought half as much, they would be just as healthy"), a flat increase in drug tax would at best make this effect true on average.

Due to higher taxation, low-income individuals would have even less access to medicine than today. Keeping people away from drugs with prohibitive taxation means starving entire demographics of this component of health care.

So sure, people who have the funds to take excessive amounts of medicine may be "just as healthy." Others would be considerably worse off.

Encrypting anything with your Google Accounts password doesn't really make you invulnerable against Google. They can get your clear text Google Accounts password from you any time they want by just reading the password you enter on any of their clients.

What key are you going to encrypt these passwords with?

If you were to encrypt passwords in the cloud with a key that's stored on the device, you can't unlock the passwords on a different device (or the same device after flashing), which is the whole point of backing it up in the cloud.

If you were to encrypt them with the user's Google Accounts password, the device would need to ask for that password on every startup or store the GA password on the device at all times (the latter option is a far greater evil than the current "situation"). As long as Google is ever given the clear text password (i.e., before hashing), this would be open to interception by Google -- or infiltrators thereof.

If the GA password were to be used to authenticate in a way where Google doesn't get access to the clear text password (through digest-like authentication), a user wouldn't be able to access the backups after resetting her password. However, this method is not reliable if you don't trust Google (or its infiltrators), because Google provides the clients that would do the hashing before sending the password, so they could obtain the clear text password (by skipping the hash step, or by sending it through side channel) on any client they control such as HTTP login pages or mobile apps provided by Google.

Like all things security, it's a trade-off between security and convenience.

It's fantastic. Note that it's from their own original press release: http://investor.yahoo.net/releasedetail.cfm?ReleaseID=765892

Again I run into the issue that Google doesn't seem to release their iPhone apps internationally. I'm in Europe (Iceland, specifically) and I can't download the Google Search or Google Authenticator apps because they're not available in our App Store.

Does this happen to people in any other European countries?

OP was clarifying the meaning of pirate in the present context, not the origin of the term or how it is used in some other contexts. The meaning you're suggesting is very explicitly not the idea behind the Icelandic Pirate Party.

At one point, they publicly rejected any affiliation with The Pirate Bay and said that they did not condone copyright violations.

They did however use the opportunity to encourage people to learn about openly licensed content, mentioning Paulo Coelho as an example, and suggesting that people consume free content no less than they do paid content. However advisable or realistic that actually is, it's not supporting illegal downloads.

Yes, and even if they had resources and interest to distribute it rapidly, I'd venture to guess that $200 would be underpricing it.

People might say they're prepared to pay less for it now than when it's reached some adoption and they start feeling the social pressure of "everybody has it; I must get one." For now it's probably more of a futuristic toy to them.

Indeed, although I don't agree "internet-enabling software" is trivial in terms of engineering and support costs, considering the range of devices today. But mostly I just wanted to clarify on the point that interception is not fully transparent: that the ISP does need to compromise every device that connects to the network.

But I do agree with your original point that to the extent possible, there should be legislation (if there isn't already) against intercepting TLS-encrypted connections of ISP customers, in cases where the ISP is also a browser-approved CA or is actually willing to distribute its own CA cert.

Nope, you're right. The ISP would have to install the CA certificate on every device on the network, which is a nontrivial task.

Furthermore, if the ISP has done that, they don't need you to go through a proxy. Your connection is already going directly through them.

Edit: However (as you can see by some of the responses in this thread), there's certainly the possibility that your ISP itself is an actual certificate authority recognized by browsers. That scenario is indeed quite worrying.

I think you're spot on that in general, the speed-quality tradeoff creates a legitimate case for content producers to choose Vimeo.

However, that's not really my complaint, but rather how slow buffering is handled by the player. In my case, the player responds to my low bandwidth by repeatedly attempting to play fractions of a second of choppy video at a time. When the player is struggling with buffering, I believe it should either downgrade the video quality or make me wait until I can watch the full video (or at least a few seconds of it) without interruption.

Strangely enough, even when the buffering progress bar makes it seem that I've loaded the next few seconds of the video, I'll get jittery video (as if the indicator is just wrong).

These are mostly player issues, and they're mostly what's putting me off about Vimeo. Now, I've been experiencing this for years on various computers and connections (of course, I don't remember the times where everything worked fine), but perhaps this is only affecting a fraction of users that I happen to belong to.

Agreed on all counts, and I'm in Iceland. I also know that local ISPs have dedicated caching servers for YouTube videos, which gives them an advantage in my region.

I realize that it's very expensive to have great connectivity in all regions, and I definitely think they should focus on player improvements (which might of course involve considerable sever work, too) since my main beef is with how slow connections are handled by the player.

Let me get a little whiny and off-topic here: the video is beautiful, but I wish people mostly stopped using Vimeo until they make their player more resilient.

It doesn't seem to degrade video quality if your bandwidth is low, it seems that my bandwidth to Vimeo is generally lower than with YouTube, it handles buffering very poorly, it's jittery on some less powerful computers, and the player itself loads noticably slower than YouTube.

For this reason, I hesitate to share the video with others, even if it's great. People going through their feeds have better things to do than wait and give up on content I attempt to share.

He was an engineering director for a couple of years working on the dev/test tool chain and Google+.

He's done a few books, including one he co-authored called How Google Tests Software, which is a fairly pragmatic discussion of large-scale testing practices at Google. (I'm not sure if this is still the case, but Nooglers used to read this book as a part of their orientation.)

Interesting how the New York Times covers this more as a threat than a political move.

The New York Times: "North Korea Warns of Pre-emptive Nuclear Attack"

BBC News: "North Korea ramps up nuclear rhetoric as UN vote looms" (http://www.bbc.co.uk/news/world-asia-21695887)

The lesson is to have more kids, fast.

It's cool, although you could have easily done without saying that yours is more interesting.

"Because participants did not ingest the glucose, they could not have absorbed a significant amount of it into their bloodstream. Moreover, it takes glucose 10 to 15 min to enter the brain after ingestion (Zourek, Jankovec, & Hykova, 2011)."

My algorithms professor is using the videos from the Sedgewick and Wayne course entirely as a way to present new material in place of lectures. He's teaching their book and his view is essentially that his time in lectures is better spent answering questions and interacting with the class than introducing new material that has been extemely well presented on the web already.

I can attest to the quality of Sedgewick and Wayne's lectures, and I have a lot of respect for my professor's humble and novel approach to teaching this course.

It's not the same. When you consume music for free, you're consuming a product without paying the person that put the largest amount of work into it. Laws aside, where's the ethics in that?

In the music business there is certainly a fairness issue of middlemen taking a large cut, but Grooveshark is not solving that.

That's true, but if more people did this, threads would be unbearable to read so I think it's better that we agree not to. Highly voted posts will appear closer to the top, so upvotes are not entirely wasted.

Why do you consider it "ideal native?"

What was a good case for a desktop app even two years ago works fine on the web today (e.g., WebGL stuff, canvas-based apps.) Chances are this will be even more true 1-2 years from now (when a product like this would have become quite polished.)

A web app can offer cheap distribution, a more iterative development cycle, split testing, more monetization flexibility, piracy protection, a larger market, immunity from platform trends, and virality (share interactive designs even with stakeholders who haven't downloaded or bought a large creative application).

Two big things I would love from a tool that intends to solve this problem well:

  - Do it on the web, making it free of platform ties.
  - Make collaboration (versioning, sharing, maybe discussion) much easier.