Windows installers aren't all the same, either, and MS Store packages typically do not even give you a choice where to install them to, dumping everything into C: by default.
Fair enough, I never heard it much myself. I guess it's better than "problematic".
What I find amusing more is that for a single mention of "Windows vs Linux" in my post about the usefulness of LLM's in software development, I got like ten off-topic responses talking about me. Then I'll get the slap on the wrist from the staff because others can't ignore me saying things like this. But I want to talk about Linux, not about me.
When I say "Windows installer" I mean a classic Win32 installer. For example, NSIS, the GNU GPL licensed framework for it. Making one is quite literally writing a script. The only thing that's different between something like NSIS and doing some form of a pre-packaged Bash script is that NSIS is streamlined into plopping an installer wizard executable that contains the program files and the installer script. What I'm suggesting is NSIS for Linux, so that software developers can package their software into an installer wizard like that, that is distro agnostic and does what you'd expect it to do. The only thing that may be controversial here is that I'm suggesting to do something in the Linux world that is done in the Windows world, and that always causes a visceral reaction from Linux people.
you can come up with the perfect solution and all it takes is a few autistic troons who don't like it to fracture the ecosystem even further. The only way you could defeat this is with insane amounts of funding and marketing, and even then it wouldn't capture the entire linux desktop ecosystem.
its important to remember just because a package shares the same source code with upstream the package itself is maintained and updated by the distro, so it doesnt matter that apt isnt the same thing as dnf. the package is still a debian package or a fedora package
My proposition would be universal across every distro. Be it CLI or GUI, Debian, Fedora or Arch. As long as it uses the Linux kernel and adheres to the FHS, this type of installer wizard would work. The Linux kernel is what executes the binaries, and FHS is how you deploy the software. /opt is there exactly for installing software like this. Software can check if it's invoked from the command line or from a GUI and launch the right form of an installation wizard so you don't need a DE to use it, and you could bundle both variants in the same installer binary.
This "the distro maintains the package" is another major issue. The distro maintainers don't have to maintain a package for something like a web browser, or any package that isn't a fundamental system package that needs to be tailored to a specific distro. It's the reason why people don't like Debian for example, it makes every package outdated, even something that realistically doesn't need to be kept that old, like Neovim. Flatpak solves that, and works across all distros, but is overly complicated. AppImage, also, fixes that, but it can't automatically update and it's restrictive in it's packaging. But both Flatpak and AppImage prove that no, the distro doesn't need to mandate which packages and which specific versions you can or cannot install, because they will simply work, they're pre-compiled binaries that don't need the distro's special sauce to run. And by doing what Windows does, which is throw all the dependencies with the program, disk space be damned, that solves the issues that mandate the distros to babysit the package versions of all software.
You get a slap on the wrist for sperging out and posting a 5 paragraph essay about shit no one cared about because someone has a different opinion than you. This entire post could be summed up as "I like the way windows installs application, and think flatpak and appimage are too over engineered. I also like offline installers for application, which Linux does not have outside those two thing." But instead people now have to go through a wall of text to ignore your niggerbabble.
Until you run a LTS distro that can't run the application because a dependency is too old, which is why Linux doesn't do that. I wonder if we could maybe ship the application with the dependencies baked in, or better yet, make a stable target for applications to base off of entirely seperated from the distro itself! Oh wait...
/opt should generally receive more love.
My issue with appimages is that they go into the home dir by default. Apps should go into /opt or /usr/bin instead and be accessible to anyone, IMO.
That would solve problems, so the fandom called Linux community will say No.
Have you checked out AppImageLauncher yet?
Flatpak/AppImage. A solution to a real problem. You could drop the dependencies alongside the binary in /opt and that'd be that. The whole shared dependencies thing only helped in reducing disk space waste by keeping redundant dependencies, which again, is a non-issue nowadays when it won't sum up to even 1GB out of 256/512GB on an average system. And what I don't understand is why no one bothered to make a way to build installer binaries like this if everything about the way software runs on Linux is down to the kernel, that's the same across all distros.
Not if the distro defaults to using it's own repo that will have a package that doesn't need to be maintained by it outdated. But Mint ships with Flatpak by default so that issue is getting better. I still think that the installer route would've been the cleanest way to go about it, zero external dependencies needed to deploy software offline or online. I do believe a form of offline distribution is good, so I guess Flatpak and AppImage are the only two forms of distributions you need to realistically target nowadays, but still, /opt seems cleaner. As native as it can be.
Good to keep in mind, thanks. By the way, even Linus admired the way AppImages go about software distribution on Linux. They're not perfect, but like I said, they'll neatly go in tandem with Flatpaks for devs to not have to deal with catering to every distro separately when all they need to run their software is the Linux kernel.
It's not like it's difficult to copy them to the place which is relevant.
Didn't Poettering in his infinite wisdom mandated that separating system and user binaries is unnecessary, so now every FHS bin directory on every systemd-based distro symlinks to /bin?
/usr/bin is typically where the package manager puts stuff. So /opt is would be the most correct place./opt and /usr/local/binWhat specific problem is there? I rarely have issues installing packages on distros these days. Even the stupid GUIs work (most of the time) these days and I hate them.
Most third-party applications normally just include anything they need. TBH, if it is a pre-compiled binary and there is a tarball, you can simply just extract the tarball, put the directory in your path, and you are done.
/opt or /bin very rarely will you be unable to have a third-party library, not unless it is expecting files to exist in certain places in the system e.g. Davinci Resolve does this, and that is why is it a bitch to get running on anything other than what they specifically support.
The problem is more on the developer side than it is on the user side. How do you package your software so that you can distribute it across the entire Linux ecosystem without having to dedicate your time to cater to every separate distro separately. If it's the distro maintainers that do it for you, then with LTS distros like Debian you'll have the issue where users are getting older versions of your package than they should. It's the distro's fault, but they'll likely complain to you. By making the software distribution hostile to the developer, you discourage supporting Linux, so Linux users ultimately suffer by having a poorer software ecosystem to choose from.
Yeah. I normally only put symlinks into /usr/bin pointing to my /opt installations.
The problem Slav Power described and which AppImageLauncher kinda solves. Kinda. It's on the user's side, not the developer's.
You can literally stick it in a tarball. I've already explained this to you before I am sure.
Why is it an issue they get an older version of the package? LTS distro makes it very clear that they support certain specific versions of things. Often you don't need the newest version of the software all the time.
It isn't hostile to the developer, though. You are just pretending it is.
Linus Torvolds is not a god, and he is frequently wrong about many things. Also, I don't care what most Linux YouTubers say, as they normally have no fucking idea what they are talking about, so please don't bother linking me them as I have no interest in listening to them. There are a handful of people on YouTube that aren't talking out of their backside when it comes to Linux.
Most of these problems he describes are the fact he wants it to be Windows and not Linux. He should just use Windows and not bother us.
AppImage* kinda solves. It's imperfect and AppImageLauncher is another half-measure to improve this imperfect solution but it's still a pretty good solution to the problem of making it easy for the developers of the software to easily package and distribute it. On both Windows and Mac it's all streamlined, you get one or two installers for each platform and you're done, you now cover everyone using those platforms. On Linux it continues to be a pain for no good reason as AppImage and Flatpak, decent solutions to this problem, show that it has nothing to do with the fact that there are different distros.
Okay. Who are you, the Linux users? What is Linux? What should it be? How should it be used? Why is it that you're hostile to the idea of giving the users a choice? Do you believe that Linux should restrict certain options? Because as far as I'm aware, Linux is just a kernel, around which anyone can build any OS they want with any features they want. You could so damn choose not to use the things I'm proposing and ignore their existence, but why should you and people like you be the ones that dictate what people can and cannot use?