I can’t blame him. I recently tried to compile a rust app from github. I did not realize that cargo was pulling a GIGABYTE of data on my bandwidth-restricted connection until it was done. Then it wouldn’t compile due to version mismatch. So I tried to update the rust version and that started throwing errors. The last thing I am doing is wasting my time troubleshooting such a crappy toolchain. If I have to play inspector gadget just to install the compiler and libraries to compile a small program, you can forget it. Cargo is a monstrosity and it is NOT a good toolchain if you value time and simplicity. I would much rather the maintainer offer binaries for download rather than requiring me to git clone, apt install, realize the deps aren’t in the apt repo, hunt down and compile the deps, run make, then troubleshoot forever and a day before I can even do make install. Just give me a binary with everything built in. Kthxbye.
What I’m hearing is you’d rather that the developer used their time to produce binaries so you don’t need to spend your own time.
The problem with open source is that people expect a lot time and effort to go into things like bug fixes, documentation and support, when often the devs start out making something to scratch a personal itch. They then share it for the benefit of others, and it can be a slippery slope where you can end up with a second job, except you don’t get paid or even thanked.
I think the difference is the intent of who will use the program.
Is the intended user the developer themselves and that’s about it but they’re making it available for others? Then just having the code is fine. It should still be properly documented however. Devs forgot their own shit code all the time, the documentation is there for them as well when they forget or come back to a project years later.
However if the program is intended for use by people outside the developers, then a regularly updated compiled binary should be expected. They are likely already going to be compiling it for themselves, making that process produce an updated binary release in GitHub isn’t too much to ask for something intended for others to use that the dev is already likely making anyway.
I see your point, but you likely also need to be compiling multiple versions for different architectures and OSes. If you offer an exe someone will turn up asking for a msi, etc, etc.
In theory, you can get this automated, but then you’re requiring a dev to learn and maintain these tools instead of working on their project.
I do edit and spell check my posts because I believe that when posting something (text, software, etc) it’s proper to make it easy to consume, without forcing dozens/hundreds/thousands of people to fix your errors. I would expect these things, but I don’t demand these things, and I think it’s inexcusably entitled for anyone to do so.
Yeah sure, I’ll compile it in my OS. For any other OS, either I’m not knowledgeable about the tools available, and many of them that I am not going to spend money to acquire. If providing the binary a developer compiles for themselves would solve it, we’d not have that problem at all.
I specifically hate when program or libraries are only in compiled form, and then I get an error messages talking about an absolute path it has with some usernames I’ve never seen before, and no way to correct it as there’s no code. Turns out when people pass compiled versions to the OS they don’t use themselves they don’t encounter the errors and think it works fine.
I disagree, Cargo is very simple and easy to use for developers.
I agree, binaries are easier for end users.
I’m surprised cargo run --release didn’t work for you. What was the project and OS?
It was meant to be humor, not a direct critique. And I don’t want help, but thanks for offering. Cargo might try to download another gigabyte of data if I touch it!
It’s really quite silly. I think all code repos on all sites should have their binaries attached to their repo. I make sure I do for every repo I maintain. Mine are usually container images, since I tend to develop services, but even if they are GUI applications, there are only a handful of binaries you would need to build and list for each release to reach 99.9% of users. Windows x86, Windows ARM, Apple x86, Apple ARM, and probably Flatpak would cover everyone on Linux (idk how to make GUI apps for Linux, I might be wrong about that). Make a script to build them all and push them all to your GitHub (or gitlab or wherever). Run the script every release. Easy peasy.
Some dude was ranting somewhere recently about GitHub and “I just want the damn exe, not a bunch of stupid code”. It became a bit of a meme.
Ahh, I was out of the loop on that meme, hah. Thanks for explaining!
@bassomitron@lemmy.world
I can’t blame him. I recently tried to compile a rust app from github. I did not realize that cargo was pulling a GIGABYTE of data on my bandwidth-restricted connection until it was done. Then it wouldn’t compile due to version mismatch. So I tried to update the rust version and that started throwing errors. The last thing I am doing is wasting my time troubleshooting such a crappy toolchain. If I have to play inspector gadget just to install the compiler and libraries to compile a small program, you can forget it. Cargo is a monstrosity and it is NOT a good toolchain if you value time and simplicity. I would much rather the maintainer offer binaries for download rather than requiring me to git clone, apt install, realize the deps aren’t in the apt repo, hunt down and compile the deps, run make, then troubleshoot forever and a day before I can even do make install. Just give me a binary with everything built in. Kthxbye.
What I’m hearing is you’d rather that the developer used their time to produce binaries so you don’t need to spend your own time.
The problem with open source is that people expect a lot time and effort to go into things like bug fixes, documentation and support, when often the devs start out making something to scratch a personal itch. They then share it for the benefit of others, and it can be a slippery slope where you can end up with a second job, except you don’t get paid or even thanked.
Open source burnout is a big problem.
I think the difference is the intent of who will use the program.
Is the intended user the developer themselves and that’s about it but they’re making it available for others? Then just having the code is fine. It should still be properly documented however. Devs forgot their own shit code all the time, the documentation is there for them as well when they forget or come back to a project years later.
However if the program is intended for use by people outside the developers, then a regularly updated compiled binary should be expected. They are likely already going to be compiling it for themselves, making that process produce an updated binary release in GitHub isn’t too much to ask for something intended for others to use that the dev is already likely making anyway.
I see your point, but you likely also need to be compiling multiple versions for different architectures and OSes. If you offer an exe someone will turn up asking for a msi, etc, etc.
In theory, you can get this automated, but then you’re requiring a dev to learn and maintain these tools instead of working on their project.
I do edit and spell check my posts because I believe that when posting something (text, software, etc) it’s proper to make it easy to consume, without forcing dozens/hundreds/thousands of people to fix your errors. I would expect these things, but I don’t demand these things, and I think it’s inexcusably entitled for anyone to do so.
Who better to compile a binary than the person that wrote the code?
Yeah sure, I’ll compile it in my OS. For any other OS, either I’m not knowledgeable about the tools available, and many of them that I am not going to spend money to acquire. If providing the binary a developer compiles for themselves would solve it, we’d not have that problem at all.
I specifically hate when program or libraries are only in compiled form, and then I get an error messages talking about an absolute path it has with some usernames I’ve never seen before, and no way to correct it as there’s no code. Turns out when people pass compiled versions to the OS they don’t use themselves they don’t encounter the errors and think it works fine.
I disagree, Cargo is very simple and easy to use for developers. I agree, binaries are easier for end users. I’m surprised
cargo run --releasedidn’t work for you. What was the project and OS?+1 for this, never had an issue with cargo pulling the wrong versions unless the dev fucks up their TOML file or you’re using the nightly toolchain
@devilish666@lemmy.world @bassomitron@lemmy.world @fishos@lemmy.world @MantisWaffle@lemmy.world
“Works on my box. You must be doing something wrong. Ticket closed.”
If I had a nickel for every …
I offered help and disagreed with what you said that was wrong. Your response is unrelated and misinterprets my reply.
It was meant to be humor, not a direct critique. And I don’t want help, but thanks for offering. Cargo might try to download another gigabyte of data if I touch it!
We all get to that point but we don’t go full meme. You never go full meme.
Isn’t there a meme about that?
It’s really quite silly. I think all code repos on all sites should have their binaries attached to their repo. I make sure I do for every repo I maintain. Mine are usually container images, since I tend to develop services, but even if they are GUI applications, there are only a handful of binaries you would need to build and list for each release to reach 99.9% of users. Windows x86, Windows ARM, Apple x86, Apple ARM, and probably Flatpak would cover everyone on Linux (idk how to make GUI apps for Linux, I might be wrong about that). Make a script to build them all and push them all to your GitHub (or gitlab or wherever). Run the script every release. Easy peasy.
I see someone who gets it …
… and doesn’t sperg a cloak of fake freedom ideology.
They’re gonna have a bad day if they ever decompress the EXE. ;)