Quoting: jensAs far as I understood eON by VP is a heavily stripped down version of wine with obviously lots of tweaks for a specific game.

No, it's an independent project. They used some ideas from Wine to improve their performance, but not the code.

View this comment - View article - View full comments

Quoting: jensI think this will even be more confusing, except for people that knows all the in's and out's of wine and its variations. Do you think that people that play "The Wintcher 2" using E-ON by VP should answer the Wine question with "yes" too? You are technically correct, but I don't think it helps here.

I guess 80% of all users talk about Steam Play when they write Proton.

eON isn't using Wine at all. If you think some question is confusing, then question should have a good clarification.

View this comment - View article - View full comments

Quoting: HoriYou all forget that there are waaay more people able to program in C than there are people able to program in Rust. Unless there's a very good improvement from which the application would get a real, noticeable benefit, you'd want to stick with the more popular choice.

That shouldn't be an impediment to use a newer language. Using this logic, everyone should have used FORTRAN forever. The benefit is always noticeable if you choose between C and Rust. The only blocker I can think of, is if the primary developer himself doesn't want to learn Rust.

View this comment - View article - View full comments

Quoting: jens- Do you use Wine (excluding Proton via SteamPlay)?
- Do you use Steam Play?

I see no point in separating Proton from Wine in the first question. Do you need to ask about every Wine fork or modification then? What about wine-esync, wine-staging or even wine+dxvk? All that, including Proton can be called Wine and derivatives.

Question about Steam Play makes sense as a separate category. It focuses not on the tool, but on the use case of integration with Steam client and also interest of people to attribute Steam purchases to Linux usage.

Those who use any variant of Wine (including Proton) but don't use Steam Play will answer Yes (Wine) / No (Steam Play). Those who use Steam Play (which implies Proton) will answer Yes / Yes. This provides a distinction in stats for both cases and you can see total Wine usage.

View this comment - View article - View full comments

Quoting: jensPlease stay with "No". Seems that Liam will add a separate question for Steam Play (https://www.gamingonlinux.com/articles/reminder-update-your-pc-info-for-the-next-round-of-statistics-updates.13034/comment_id=141516 [External Link]).

Liam said, that it means that question about Wine will include Proton then, so it should be "Yes" to the first question.

I.e. the first question is about the tool (Wine and derivatives). The second question is about Steam Play specifically (Steam feature).

If that's too confusing, it's better just to stick with one question about Wine.

View this comment - View article - View full comments

Quoting: EikeDo I update my answer from "no" to "yes" next to the question about wine if I play games through Steam Play (no wine, no Proton)?

Yes, change it. Proton used in Steam Play is a Wine variant. But there will be a separate question about Steam Play (not Proton but Steam Play specifically if I understood correctly).

View this comment - View article - View full comments

Quoting: GuestI'm talking about Steam.

Which implies that usage of Proton means using Steam, which is not correct. While Proton is targeted for Steam, it can be used without it.

View this comment - View article - View full comments

Quoting: Guestand then advocating adding Rust dependencies on top doesn't sound like a good idea in this case. I just don't see a use case for Rust for this project's goals (or at least what I'm interpreting to be the goals).

Not any more than advocating for C in this case. If you think mixing languages is bad here, it's bad with C as well. But if you think rewrite is useful, Rust only has advantages over C, offering the same functionality.

View this comment - View article - View full comments

Quoting: GuestAh ok, a personal preference thing rather than a technical one.
On a technical level, C is a better choice here, for ease of cross-platform support on something that is lower level and may require kernel interaction. Pretty much everything is going to have a form of libc, and target platforms will have a lot of support (from compilers and build systems, to additional libraries that might be needed) already in C.

It's both and the reason for preference is technical, not simply one of taste. Rust can interact with kernel all the same by the way. Rust does depend on libc at present.

See https://github.com/rust-lang-nursery/portability-wg/issues/13 [External Link]

And an interesting example here: https://github.com/tsgates/rust.ko [External Link]

View this comment - View article - View full comments

Quoting: GuestWhy?

Many reasons really. Here is one C developer putting it in more detail: https://dpc.pw/still-in-love-with-rust [External Link]

I'd highlight this part:

I loved the simplicity and minimalism, I loved the flexibility and control, but I couldn't stand primitivism and lack of modern features.

That's exactly how I feel about C, when I work with it :) I'd take Rust over C any time.

To put it differently. If you need to support an existing project - fine. But if you are making a new one (like here switching to another language), don't start it in C or C++. Start it in Rust.

View this comment - View article - View full comments