I don’t think these two games can be reasonably compared. HL2 is currently free, while concord was a paid game.

I like it :) Can you provide a link to the sensors you used?

You‘re supposed to host this yourself.

Set the DNS cache time to 60 seconds.

Set the script to run on every host delayed by some time to avoid simultaneously accessing the API (e.g. run the script every other minute).

With this approach, you get automatic failover in at most 3 minutes.

I’d host it on both webservers. The script sets the A record to all the servers that are online. Obviously, the script als has to check it’s own service.

It seems a little hacky though, for a business use case I would use another approach.

If it’s a civil and interesting discussion, why not?

OP said that they have a static website, this eliminates the need for session sync.

Your challenge is that you need a loadbalancer. By hosting the loadbalancer yourself (e.g. on a VPS), you could also host your websites directly there…

My approach would be DNS-based. You can have multiple DNS A records, and the client picks one of them. With a little script you could remove one of the A Records of that server goes down. This way, you wouldn’t need a central hardware.

You can trim it even further:

https://www.amazon.com/dp/B0B6HKB3JF/

For a start, try hosting something in your own home. A raspberry or an older PC or laptop should be enough.

My first projects were a print server (so I can print via wifi) and a file server. Try to find something that is useful for you.

Only start hosting on the internet when you’ve learned the basics and have more experience.

They should have split it so both of them can enjoy at least 50% of it.

I agree, but I understood this question in the context of a homelab.

And for me, a homelab is not the right place for a public website, for the reasons I mentioned.

No, with these reasons:

• Bandwidth isn’t plenty
• My “uptime” at home isn’t great
• No redundant hardware, even a simple mainboard defect would take a while to replace

I have a VPS for these tasks, and I host a few sites for friends amd family.

I got it a few times over the last years, once on the steam deck.

Just one open source example … freeradius has an option to log passwords:

log {
    destination = files
    auth = no
    auth_badpass = no
    auth_goodpass = no
}

Or another example: The apache web server has a module that dumps all POST data, with passwords, in plain text:

mod_dumpio allows for the logging of all input received by Apache and/or all output sent by Apache to be logged (dumped) to the error.log file. The data logging is done right after SSL decoding (for input) and right before SSL encoding (for output). As can be expected, this can produce extreme volumes of data, and should only be used when debugging problems.

I don’t agree that this is “absolutely malice”, it could also be stupidity and forgetfulness.

This is not about facebook not hashing credentials, it is that they appeared in internal logs.

Facebook is probing a series of security failures in which employees built applications that logged unencrypted password data for Facebook users and stored it in plain text on internal company servers.

Source: Krebs on Security

By supporting work on a freelance basis

This sounds like Valve is paying devs to work full time on arch, and thus managing to achive more than volunteers could.

Thanks for the hint on nVidia. That might explain my issue

It is good that they are easier to read, because they are about as long as the first book of The lord of the rings.

You’re right, Google released their vision in 2023, here is what it says regarding lifespan:

a reduction of TLS server authentication subscriber certificate maximum validity from 398 days to 90 days. Reducing certificate lifetime encourages automation and the adoption of practices that will drive the ecosystem away from baroque, time-consuming, and error-prone issuance processes. These changes will allow for faster adoption of emerging security capabilities and best practices, and promote the agility required to transition the ecosystem to quantum-resistant algorithms quickly. Decreasing certificate lifetime will also reduce ecosystem reliance on “broken” revocation checking solutions that cannot fail-closed and, in turn, offer incomplete protection. Additionally, shorter-lived certificates will decrease the impact of unexpected Certificate Transparency Log disqualifications.