cf

dual booting is a kinda a lot of work just for some free games.

You also could charge a dollar since you are often offering a strictly worse product for Linux users. That's what happens in many other markets when you are trying to expand a userbase.

There is clearly a dollar value to providing support. Why shouldn't the price reflect that?

Thanks! And believe me I want to be proved wrong on this. If you find any developers that were motivated to create a native Linux port of their game due to strong numbers on Proton I want to know!

There were Linux ports before Proton and I'm making the case that Proton does not create the right incentives to grow a market for Linux games.

Like imagine a restaurant that served food to people in suits and people in tshirts but the people in tshirts tended to get food poisoning significantly more often. Would you consider the response to this concern "If you don't want food poisoning maybe wear a suit next time" a reasonable response?

Basic question, if someone buys a game to run it through Proton do they look like a Windows or Linux user on your end?

How would you feel about games being made available for free to Linux users if it uses Proton. If the game contributes basically nothing to your bottom line and you don't plan to support them anyways, why not? It will only grow the audience more quickly.

This has always been true, but Linux gets treated worse than OS X even though those users also have tiny market share.

Sure thing.

Supergiant has previously released all their games (Bastion, Transistor, Pyre) with Linux support. With Hades they explicitly said would not come to Linux, and in fact cite the presence of Proton as a reason [1]

Nicalis games has released games like Cave Story, VVVVVV and Binding of Isaac with Linux support. But the latest DLC of BoI will not have Linux support.

1. https://steamcommunity.com/app/1145360/discussions/0/1639794...

The problem with Proton is it is leading many game developers to actually drop Linux support. They basically say players seem to be able to get the game to work on Proton and that's that.

But with no official support there is no guarantee it will continue to work with updates. There is no promise to even try to make it work if it breaks. And that's the major stuff. Imagine spending 20, 30, or 60 dollars on a game that can break at any moment and know there will be zero support waiting for you. And that's hard breaks. Performance hiccups will be given zero attention by the developers.

There is all this talk that Proton will make people want to develop native Linux ports but I don't see any data or logic to back that up.

Hard to edit from a text editor and requires using something specialised

I don't think there should be any single entity responsible for archiving. If you want something preserved there needs to be multiple copies across different organisations.

No conversation about England and housing is complete without discussing Right to Buy where affordable public housing is privatised and then has its value rapidly rise to meet market prices.

You say quaint. To me it seems remarkably out of touch with the real problems Americans face.

Well there is a dedicated paper on it. The short answer is the English description helps a guided search

https://arxiv.org/abs/2003.09040

This looks really cool! I gotta figure out a way to contribute to this. Is this what OsmAnd uses to pull in transit information?

What's the best way to help? Do I just add the feeds to another website somewhere?

I'm curious is there something like OSM but for directions using public transit? Some public repository of bus and train times.

Thanks for finding that detail. I went to that article and missed it somehow.

I'm fairly sure Courant was persecuted for being Jewish. Other biographies are pretty clear on this and I can find no reference to what political party Courant belonged to in Germany.

If you want something pithy. AD makes it easy to compute derivatives, PPLs make it easy to compute integrals. In particularly, the kind that come from taking the expectation of a function with respect to some probability distribution.

I thought with libraries like Zygote there is some really nice stuff already in Julia. I'd say it's still early days for good autodiff libraries in general and I think we still haven't really explored what they can do.

The reality is that most of a modelling task is preprocessing your data before it can be passed to a probabilistic model and postprocessing to make decisions using it. The code is usually written in R or Python so there is a strong pressure for your library to be in that language as well.

And being rough around the edges is an ok price to pay for not losing an ecosystem.

I think systems built around effect handlers like pyro and edward2 form a nice corner in the design space by being less reliant on metaprogramming, being fairly composable, and give nicer UIs.

The downside is a trickier to write and debug API on the inference developer's side. Do link your library as I try to evaluate every PPS I encounter.

The reason Julia is a good fit is it has both good numerics support (arrays, matrices, autodiff, samplers, etc) and good metaprogramming support. Probabilistic programming systems really need both to feel natural and well-integrated while still being able to have nice inference algorithms.

A PPS in an environment without those two things is at a disadvantage.

Why not? If you pick your model well incremental updates to the model can be made fairly cheap.

An open source example that's relatively usable can be found at http://probcomp.csail.mit.edu/software/bayesdb/

The main simplify function is full of heuristics and is itself a basket of more specialised simplify functions. One thing to try one or several of these specialised functions.

Another tip I don't think gets mentioned enough, try to provide domain information for your symbolic variables. By default all these systems assume the most general solution. But if you know x is a positive real value, you should tell that to SymPy.

You should definitely raise an issue if you got the bandwidth. The project has generally been responsive on this sort of stuff.

Oh man this is like 90% of what I wanted to make! Thanks for making this open-source!

Yes I want to adjust remote audio streams but I don't see where in the API I can iterate over each user's audio feed.

One thing I've wanted to make is something like gather.town where I can remix the audio and video so that different users sounded louder or quieter. But, I never figured out where in the WebRTC API that is done. It seems like I need to set up my own SFU and put the necessary logic over there.

Oh my god, I had the same thought and forgot how readily this features actually exists.

I suppose I still like the idea of persisting those changes for websites I control but that's going to be way less straightforward.

Are there any good tutorials for how to setup Jitsi to work for 30-50 people? The discussion forums are hard to navigate.