3 ms·

To me the worst case is trying to develop some small utility like a tool to search in files using regex. Because if you are developing something large, the amou

To me the worst case is trying to develop some small utility like a tool to search in files using regex. Because if you are developing something large, the amount of time you spend dealing with packaging, distribution, etc., is small and you don't care about file sizes. But if I want to, say, develop the app for Windows. That is easy. You get a tiny binary to just opens a form and runs with a double click. No install necessary. The same thing on Linux? Impossible. There is no guarantee the machine has any version of GTK or Qt installed at all, so to be self-contained you need to ship the entire OS. Now your file size is huge. I can't use Python, because now Windows users need to have Python or I have to ship an interpreter. The only plausible alternative is something like Java. Now you have a single .jar file that runs on any system. But then Oracle changed the license, and JavaFX is no longer part of Java (Swing still is). Honestly, I just want to display a menubar with keyboard shortcuts. Why can't there be a menubar VM or something that gives me access to a menubar on all OS's without having to deal with all of this. We are already shipping the entire browser with Electron. That is stupid. The way it should work is users install a something like Flash but for desktop apps and every app just uses that platform. It's probably easier to ship a DOS game than a desktop app because everyone who wants to run a DOS game will just have a DOS emulator installed.

polski-g 5mo ago
I want to say you could statically link a GUI application, but I'm pretty sure libpthread doesn't cooperate on static linking.
- badc0ffee 5mo ago
  libpthread is fine with static linking. Where you run into issues is libraries like libresolv that use configuration files in a specific path.
einpoklum 5mo ago
> There is no guarantee the machine has any version of GTK or Qt installed at all, so to be self-contained So don't be self-contained. I mean, you depend on an X server or Wayland, right? So why not depend on GTK or Qt being available? (Of course, it _is_ tricky to be able to depend on any of several versions of these, but still.)
- AlienRobot 5mo ago
  What I mean is that on Windows you can just ship an 100kb .exe and forget about it and it's still going to work 20 years later. On Linux that doesn't happen. First of all you HAVE to ship the source code if you want it to keep working on every machine because people need to compile it on their machine for it to work, so you're practically forced to open source your desktop app. I know the notion of having a closed source app on Linux sounds weird, but it's more weird that this isn't an option as a side-effect of the how the whole system is designed. Second of all, even if you do ship the source code, you're going to be forced to maintain it. If you made an app in GTK 1 (which looks beautiful, by the way, compared to modern GTK), people won't be able to just install it because GTK 1 is so old that it's no longer in the repositories. An app made in Java 8 runs in the modern VM. An app made for Windows 95 still runs on modern Windows. It's only on Linux that I feel like the developer is pressured to open source it and make it the user's problem because the system won't provide support.
  - okanat 5mo ago
    I'm not defending this but there was (or has been) enough political motivation and intentionality in GNU/Linux systems to make binary compatibility a hassle. People actually made decisions against backwards compatible APIs, intending to cause issues and forcing open-sourcing. Binary compatibility means closed source has a chance to grow in an ecosystem. It requires "responsible" developers to put more effort into designing APIs and keeping them alive. It adds complexity that requires a more stable set of long-term developers; in contrast, the constant churn in FOSS requires lower barriers for contributions. With stable APIs/ABIs you have to live with decade-long mistakes. You cannot "just fix it" in a next major bump.
    - GoblinSlayer 5mo ago
      >People actually made decisions against backwards compatible APIs, intending to cause issues and forcing open-sourcing. You mean openssl? That said, if we can have /dev/tcp, why we can't have /dev/ssl?
  - skydhash 5mo ago
cmacleod4 5mo ago
"worst case is trying to develop some small utility like a tool to search in files using regex" - you mean something like: https://wiki.tcl-lang.org/page/ReacTcl+example%3A+Grv https://wiki.tcl-lang.org/page/ReacTcl+example%3A+Grv ? This will run on Windows, Linux, MacOS, and Tcl's starkit/starpack system makes it easy to generate a single executable file for each OS that can just be copied over and run without any installation needed.

polski-g 5mo ago

I want to say you could statically link a GUI application, but I'm pretty sure libpthread doesn't cooperate on static linking.

badc0ffee 5mo ago
libpthread is fine with static linking. Where you run into issues is libraries like libresolv that use configuration files in a specific path.

einpoklum 5mo ago

> There is no guarantee the machine has any version of GTK or Qt installed at all, so to be self-contained So don't be self-contained. I mean, you depend on an X server or Wayland, right? So why not depend on GTK or Qt being available? (Of course, it _is_ tricky to be able to depend on any of several versions of these, but still.)

AlienRobot 5mo ago
What I mean is that on Windows you can just ship an 100kb .exe and forget about it and it's still going to work 20 years later. On Linux that doesn't happen. First of all you HAVE to ship the source code if you want it to keep working on every machine because people need to compile it on their machine for it to work, so you're practically forced to open source your desktop app. I know the notion of having a closed source app on Linux sounds weird, but it's more weird that this isn't an option as a side-effect of the how the whole system is designed. Second of all, even if you do ship the source code, you're going to be forced to maintain it. If you made an app in GTK 1 (which looks beautiful, by the way, compared to modern GTK), people won't be able to just install it because GTK 1 is so old that it's no longer in the repositories. An app made in Java 8 runs in the modern VM. An app made for Windows 95 still runs on modern Windows. It's only on Linux that I feel like the developer is pressured to open source it and make it the user's problem because the system won't provide support.
- okanat 5mo ago
  I'm not defending this but there was (or has been) enough political motivation and intentionality in GNU/Linux systems to make binary compatibility a hassle. People actually made decisions against backwards compatible APIs, intending to cause issues and forcing open-sourcing. Binary compatibility means closed source has a chance to grow in an ecosystem. It requires "responsible" developers to put more effort into designing APIs and keeping them alive. It adds complexity that requires a more stable set of long-term developers; in contrast, the constant churn in FOSS requires lower barriers for contributions. With stable APIs/ABIs you have to live with decade-long mistakes. You cannot "just fix it" in a next major bump.
  - GoblinSlayer 5mo ago
    >People actually made decisions against backwards compatible APIs, intending to cause issues and forcing open-sourcing. You mean openssl? That said, if we can have /dev/tcp, why we can't have /dev/ssl?
- skydhash 5mo ago

cmacleod4 5mo ago

"worst case is trying to develop some small utility like a tool to search in files using regex" - you mean something like: https://wiki.tcl-lang.org/page/ReacTcl+example%3A+Grv https://wiki.tcl-lang.org/page/ReacTcl+example%3A+Grv ? This will run on Windows, Linux, MacOS, and Tcl's starkit/starpack system makes it easy to generate a single executable file for each OS that can just be copied over and run without any installation needed.