Linux

It is, that's what Windows does. It's also possible to compile programs to not need external libraries and instead embed all they need. But both of these are bad ideas.

Imagine you install dolphin (the KDE file manager) It will need lots of KDE libraries, then you install Okular (KDE PDF reader) it will require lots of the same library. Extend that to the hundreds of programs that are installed on your computer and you'll easily doubled the space used with no particular benefit since the package manager already takes care of updating the programs and libraries together. Not just that, but if every program came with it's own libraries, if a bug/security flaw was found in one of the libraries each program would need to upgrade, and if one didn't you might be susceptible to bugs/attacks through that program.

That is possible indeed! For more context, you can look up "static linking vs dynamic linking"

Tldr: Static linking: all dependencies get baked into the final binary Dynamic linking: the binary searches for libraries in your system's PATH and loads them dynamically at runtime

Absolutely! That's called static linking, as in the library is included in the executable. Most Rust programs are compiled that way.

In addition to static linking, you can also load bundled dynamic libraries via RPATH, which is a section in an ELF binary where you can specify a custom library location. Assuming you're using gcc, you could set the LD_RUN_PATH environment variable to specify the folder path containing your libraries. There may be a similar option for other compilers too, because in the end they'd be spitting out an ELF, and RPATH is part of the ELF spec.

BUT I agree with what @Nibodhika@lemmy.world wrote - this is generally a bad idea. In addition to what they stated, a big issue could be the licensing - the license of your app may not be compatible with the license of the library. For instance, if the library is licensed under the GPL, then you have to ship your app under GPL as well - which you may or may not want. And if you're using several different libraries, then you'll have to verify each of their licenses and ensure that you're not violating or conflicting with any of them.

Another issue is that the libraries you ship with your program may not be optimal for the user's device or use case. For instance, a user may prefer libraries compiled for their particular CPU's microarchitecture for best performance, and by forcing your own libraries, you'd be denying them that. That's why it's best left to the distro/user.

In saying that, you could ship your app as a Flatpak - that way you don't have to worry about the versions of libraries on the user's system or causing conflicts.

Appimage might also be a way

When having a breaking change pre 1.0.0, I'd expect a minor version bump instead, as 1.0.0 signals that the project is stable or at least finished enough for use.