Can you chat in both directions or is simplex uni-directional?

How does one have a unidirectional chat?

I hope this is satire.

Lots and lots of programmers have very little understanding and especially operation knowledge of how to host a public service. You can be an extreme graphics programmer and not know the web stack at all.

And no, its not that hard once you learn. Except, now its a never ending chore when it was an appliance. Instead of a car you have a project car.

> Lots and lots of programmers have very little understanding and especially operation knowledge of how to host a public service. You can be an extreme graphics programmer and not know the web stack at all.

Can confirm.

Also, not everyone who wants to share content publicly has a domain name with which to do so, or the kind of Internet connection that allows running a server. If you include "hosting" by using a hosting provider... it's perfectly possible (raises hand) to not even have any experience with that after decades of writing code and being on the Internet. (Unless you count things like, well, GitHub and its services, anyway.)

On the other hand you probably don't need to go full k8s and datadog on it. Just host it. Use a PaaS so you don't need to do Linux admin.

I think both of you are misunderstanding what I proposed. You just need a single VM with an ssh server. Literally no web service needed, if all you want to do is host some code remotely.

I didn't misunderstand. Sshd is a web service. Most folks don't already know how and don't want to set up a machine that is always on, that will restart on power loss, that will have a static IP or dynDNS, with a domain name and proper routing and open ports and certs and enough bandwidth and that's before you even worry about actual security and not just what is needed to work.... It's actually a big annoyance if you don't do it all the time.

ssh isn't a web service (some would argue that smtp and ftp aren't too as they came before the web).

And I believe GP was talking about the only thing you need is:

  ssh user@remotehost git init --bare repo.git

And then you can add the remote to your local repo with

  git remote add origin user@remotehost:repo.git

Now all you need to do is

  git push origin branch_name

Replace origin with another identifier if it's already taken.

The rest of the owl: go to provider, set up VM (20 questions) log into root. SSH for login. set up firewalls. create non-root user. useradd or adduser? depends if you want a home dir I guess. debug why you can't ssh in. Finally get in. sudo apt update. sudo apt install git (or is it named something else?). install failtoban. install fw.

then do above.

then troubleshoot.

set vm backup policy.

save myriad passwords and secret to bitwarden.

get ubuntu to stay up to date.

I could write a much more complicated list of steps for github.

VM and ssh. Needs linux admin exp. Security updates. Understand how to securely connect from an IP without opening 22 on 0.0.0.0/0

Opening ssh to the internet is fine if you are using key based auth, which is the default on many VM setups.

For what its worth, it's pretty easy to maintain a low traffic Gitlab instance.

So if you need to conditionally tick something or you want to wait for an effect to finish, etc., you're using Update() with if() statements?

The same code in a coroutine hits the same lifecycle failures as Update() anyway. You don't gain any safety by moving it to Update().

> No structured cancellation.

Call StopCoroutine with the Coroutine object returned by StartCoroutine. Of course you can just pass around a cancellation token type thing as well.

> Hidden allocation/GC from yield instructions.

Hidden how? You're calling `new` or you're not.

Instead of fighting them, you should just learn how to use coroutines. They're a lot nicer than complicated logic in Update().

Enjoy shipping console titles that run at a constant 60 fps with no GC.

Again, fine for pet projects on PC :)

I'll continue to bite... What AAA 60+fps mobile game written Unity without coroutines are you referring to?

There's exactly 0 (zero) AAA games made with unity so it's going to be tough. They're all a terrible lag fest no matter how they're implemented

Genshin Impact makes billions and it's made in Unity. Seems to be good enough for them.

It feels hacky because you have to (had to?) use it as the async/await tool and because of that the types you're generating and how they are handled is a huge mess.

Really you're generating the vague concept of a yield instruction but you can return other coroutines that are implicitly run and nest your execution... Because of this you can't wait less than a frame so things are often needlessly complicated and slow.

It's like using a key to jam a door shut. Sure a key is for keeping doors closed but...

Use Rider or Visual Studio. Debugging coroutines should be easy. You just can't step over any yield points so you need to break after execution is resumed. It's mildly tedious but far from impossible.

You can structure coroutines with a context so the runtime has an idea when it can drop them or cancel them. Really nice if you have things like game objects with their own lifecycles.

For simple callback hell, not so much.

It might be a case where they're projecting costs and a pessimistic Fortnite market a few years out. I doubt this something you do after the money is gone. You'd look ahead and see your runway in a down market is way too short and cut costs.

You can't just bet the farm on dropping a new $5B/year game.

The point is that Proton puts them in a win win position. If Windows stays popular, they're fine. If Windows tanks, they're fine.

If Windows tanks their fountain runs dry.

What is the scenario where windows becomes so unpopular, computer games stop being made entirely instead of another OS filling that gap?

The doom that is repeated all the time on Linux forums, or even here.

The industry will adapt quickly, especially the part that's using multiplatform mainstream engines like UE/Unity.

Lots of new/recent native MacOS releases nowadays: https://store.steampowered.com/macos

The same that support Linux and yet Valve has to come up with Proton.

Developers chase the user base. If and when the users choose Linux developers will target Linux.

Proton as a project let's valve hedge on the heir apparent OS without upfront developer cost. If the Linux player base grows, developers will follow and valve is poised to remain dominant.