Costs money and is centralized with a for-profit entity, probably best to stay far away when it comes to day-to-day software.
Don't get me wrong, I love Steam, but for video games. You can't stop auto-updating for example, and still be able to launch the "game" (program in this case) if it's out of date, which obviously breaks pretty much every professional computer user's workflow.
It doesn't have to cost money. You can write a normal Windows app and run it under Proton. For end users, provided that they have Steam installed (it's free), they can just add "Non-Steam game" to the library - it's ~4 clicks.
It works. It works great. It's actually the only sensible solution if you want something compiled today to work without changes on both Windows and Linux in 10 years.
I did an experiment, implementing a GUI calculator, and Rust + Slint + cross-compiling to Windows (I develop on Linux) + Proton runtime was the clear winner:
- compiled bundle: 20 MB (F#/dotNet + Avalonia: 207 MB)
- loc: ~1000 (dotNet: ~700)
- dlls: none other than what Wine provides (dotNet: 67 .dll files)
You have an option to build for Linux for dev/testing, then you cross-compile to Windows and provide a short (4 points) instruction for adding the Windows build to Steam on Linux. It works, and it will most likely continue to work in the future, unless Valve folds and both Wine and Proton die. The only thing worth looking out for is crates that depend on external shared libraries: you need to bundle them manually. Other than that, it works.
Another option I considered was Zig with the Win32 API, but the LOC count was unacceptably high.
I'm working on a write-up for the experiment. The premise was: "I'm working on Linux and want to create a GUI app that will, with the build done today, continue working on Windows and Linux for the next 10 years". Steam/Proton + mostly static compilation + bundled libraries is the only solution that makes this mostly painless.
> It doesn't have to cost money. You can write a normal Windows app and run it under Proton. For end users, provided that they have Steam installed (it's free), they can just add "Non-Steam game" to the library - it's ~4 clicks.
I'm saying you don't need to publish on Steam to make your app run on Steam. You really don't. A user can add any executable to the Steam Library via the "Add a Game -> Add Non-Steam Game" button in the bottom-left corner of the GUI. It works 100% locally and with any kind of executable (not just games). It also bypasses any auto-updates. Finally, you can launch an app like that from the CLI or a desktop shortcut without opening Steam (well, it'll still run and update itself when needed, but you bypass the GUI).
> A user can add any executable to the Steam Library via the "Add a Game -> Add Non-Steam Game" button in the bottom-left corner of the GUI.
Yeah, but that's also not exactly a better user-experience for the end-user than "Download .exe, double-click to launch" or "Download .msi, finish install, run program".
Distribute your software however you want, I tend to try to make the download and install as familiar as possible to the users of the specific platforms.
Btw, even your starting prompt is guiding the model to just agree with your opening statement. You can't just roll with whatever the model says and assume the conclusion of "definitely can run in 10 years unchanged" is true.
Yeah, that's why the second prompt starts with "You misunderstood" and a correction. This is a long conversation, with multiple experiments performed and a lot of inspection of all the intermediate results on my end between prompts. You assuming otherwise without reading is a bit offensive.
To your point on installation: sure, but if you value it that much, just pay Valve to add you to the Steam store? And that would be the only possible solution given my constraints, all explicitly mentioned at least once in the linked conversation:
- binary produced today works
- without changes
- on both Linux and Windows
- is a GUI app
- has some dependencies
- is developed on Linux (no Windows needed)
For this set of constrains, Proton/Wine with a cross-compiled Win32 binary/bundle is literally the only solution (care to name another?)
For other constraints, it's a solution. Worth considering. That's all.
> You assuming otherwise without reading is a bit offensive.
Yeah sorry, hurling huge LLM conversations at me tends to make me skim them, hope you don't mind I didn't study the conversation you had with ChatGPT in detail.
That you considered someone skimming a chat log offensive yet the act of sharing those chat logs and expecting others to dredge through them, is almost offensive to me. So I guess we can call it even now.
> For this set of constrains, Proton/Wine with a cross-compiled Win32 binary/bundle is literally the only solution (care to name another?)
Cross-compiling the good old way, with a Linux VM, Windows VM and a macOS host (maybe Mac Mini?). I basically have the very same requirements (+ macOS), except zero third party dependencies, and end up doing it this way, all managed with Nix so basically all the installation-bloatyness is something I deal with so users get the exact same experience they expect on their OS.
Steam provides a stable Linux runtime, but it's not containerized or isolated Docker/Flatpak-style. It's closer to a chrooted env with some specific distro, but without chroot and the need to maintain said distro. They want to provide runtime stability and compatibility comparable to that on Windows - it's a great initiative, and I really hope they'll succeed. The snowflake-like userlands on Linux are a pain, but the current solutions (Docker, Flatpak, things like conda) are all bad solutions to this particular problem (though they are good solutions to other problems, so it's not a criticism, just a difference in goals).
However, Steam Runtime for Linux was still in beta, last I checked. Plus, it doesn't solve the cross-platform part. But for Linux-native development, Steam Runtime might be what's needed to have long-term compatibility for apps (finally).
The wealthy Quaker drivers thing threw me. I know it's an exaggeration but is there a large enough wealthy Quaker driver population drivers ubers for this to be a concern?
I highly doubt that there is. I'm just saying that if you can discriminate on drivers based on protected characteristic Y and data suggesting that characteristic Y is more/less dangerous, then you should be able to discriminate on protected characteristic X based on similar data, or both characteristics X and Y, or characteristics X, Y, Z, U and W.
If characteristic X was race, religion or sexuality, I think people would be extremely opposed to this, and not even entertain the idea that this would be acceptable.
You don't have to dance around it. That's exactly what's happening. The people here who are saying it's okay to discriminate against men because "they" commit sexual assaults at a higher rate, those same people would (rightly) lose their minds if anyone suggest that we should discriminate against African Americans if they were to commit some violent crime at a higher rate.
We need to call a spade a spade here. This is blindly terrible logic. It's crass sex discrimination, and it's affect people's ability to find employment, and it's almost certainly against the law.
Deciding we can just start discriminating against an entire class of people in employment or housing, just because their is a subset of that class committing crimes is a civil rights violation.
People need to stop treating this like it's somehow okay because it's men.
I wouldn't usually have responded, but "treating a question as an attack or criticism" is a particular bugbear of mine. We can't grow, learn, or understand one another if questions are by-default treated with hostility or defensiveness.
I could play devils advocate and say that it’s bad for poor students because if authors are not fairly compensated then these authors won’t write textbooks and if they don’t then future students won’t benefit from having the textbooks.
I mean yeah, getting your work published just means that you can sue if someone steals it (often the case with those university presidents that they plagiarized work from undergrads or those who otherwise couldn't fight back). But if publishers stop making money off academic texts, then they won't be inclined to fight those battles. Then again, a lot of the money comes from university library subscriptions to entire catalogues of texts including books and articles, so either something you want to access is already in your ecosystem or it isn't.
When my courses had profs who had written the book, they'd have the school book store print and bind them to booklets, and sell them for close enough to cost, and also put up a download link for the pdf
Well when you get sick from the weird bacteria after buying tattoo ink on Amazon you can go Amazon Health to get better. It's the snake that keeps eating itself.
