Sebb767

> Sure, but a reasonable user would expect that condition to be implicit in using a commercial model.

In fact, adding it might make things worse as it shows at least some awareness of the risks.

The live-video.net domain belongs to Twitch. So, from what I can gather, apparently the OP switched back to Twitch streaming and the last-hop RTMP server does not use certificates.

As the famous saying goes: If you owe the bank a million dollars, you have a problem. If you owe the bank a billion dollars, the bank has a problem.

> - "Prefer New" seems almost useless. You've already spent all this effort doing the job, why are you cancelling it and throwing away the results?

The obvious use-case is if the result depends on a state and the state has changed since the job has started. Examples would be updating the landing page when a new article has come in (you don't need the outdated landing page w/o the new article) or if you did a code change while compiling (assuming it's not a commit).

Which model and how can you achieve that speed, if you don't mind me asking?

Usually, yes. There are a few exceptions, such as serious misconduct, tax fraud and not declaring insolvency when necessary. But as long as you're following the law, you're fine.

> I hope there's always someone willing to make this bet and release better and better open models.

What would this bet be? Training is expensive and open weights mean that for hosting you compete on price with people that don't have this item on their bill.

> Unless you have a “every commit must build” rule, why would you review commits independently?

Security. Imagine commit #1 introduces a security vulnerability (backdoor) and the features. Then #2 introduces a non-obvious, harmless bug and closes the vulnerability introduced in #1 [0]. At some point, the bug will surface and rolling back commit #2 will be an easy fix, re-introducing your bug.

Alternatively, one of the earlier commits might, for example, contain credential dumping code. Once that commit is mainlined, CI might either automatically run on it or will be able to be run on it since it's no longer marked as unsafe PR.

[0] Think something like #1 introduces array access and #2 adds a bounds-check in a function a layer above - a reviewer with the whole context will see the bounds check and (possibly) consider it fine, but to someone rolling back a commit the necessity will not be obvious.

What was the issue with the Nord line?

Each of our devices spents a lot of energy dedicated to encryption. By now, all disks you did not set up manually are most likely encrypted and hardly any unencrypted package will travel out of your network. That's not to mention the tons of load and dedicated hardware we have just to terminate https and scan traffic for suspicious activity or the hardware being replaced because it's internal security triggered/broke.

In a perfect world, we could send all traffic completely unencrypted and never scan for a malicious payload, saving all that energy and hardware. But we do not live in that world and drawing the line with this minor, mostly unintrusive security feature seems strange.

Usually, it will be where the passenger side is in the cars home market. That is left for Japanese and British vehicles and right for US and German ones.

Fun fact, for single exhaust cars, the exhaust will usually be on the driver side, in order to route around the fuel tank :-)

> Probably because actual time required to manage a db server is really unpredictable.

This, and also startups are quite heterogeneous. If you have an engineer on your team with experience in hosting their own servers (or at least a homelab-person), setting up that service with sufficient resiliency for your average startup will be done within one relaxed afternoon. If your team consists of designers and engineers who hardly ever used a command line, setting up a shaky version of the same thing will cost you days - and so will any issue that comes up.

I dislike those black and white takes a lot. It's absolutely true that most startups that just run an EC2 instance will save a lot of cash going to Hetzner, Linode, Digital Ocean or whatever. I do host at Hetzner myself and so do a lot of my clients.

That being said, the cloud does have a lot of advantages:

- You're getting a lot of services readily available. Need offsite backups? A few clicks. Managed database? A few clicks. Multiple AZs? Available in seconds.

- You're not paying up-front costs (vs. investing hundreds of dollars for buying server hardware) and everything is available right now [0]

- Peak-heavy loads can be a lot cheaper. Mostly irrelevant for you average compute load, but things are quite different if you need to train an LLM

- Many services are already certified according to all kinds of standards, which can be very useful depending on your customers

Also, engineering time and time in general can be expensive. If you are a solo entrepreneur or a slow growth company, you have a lot of engineering time for basically free. But in a quick growth or prototyping phase, not to speak of venture funding, things can be quite different. Buying engineering time for >150€/hour can quickly offset a lot of saving [1].

Does this apply to most companies? No. Obviously not. But the cloud is not too expensive - you're paying for stuff you don't need. That's an entirely different kind of error.

[0] Compared to the rack hosting setup described in the post. Hetzner, Linode, etc. do provide multiple AZs with dedicated servers.

[1] Just to be fair, debugging cloud errors can be time consuming, too, and experienced AWS engineers will not be cheaper. But an RDS instance with solid backups-equivalent will usually not amortize quickly, if you need to pay someone to set it up.