4 ms·

I believe 50MB is an exaggeration, but not too far-fetched one. More of a problem is the proliferation and duplication of these DLLs all over the storage when m

I believe 50MB is an exaggeration, but not too far-fetched one. More of a problem is the proliferation and duplication of these DLLs all over the storage when many Qt-based apps are installed. A quick Everything query shows that right now I've got 290MB of Qt*.dlls on my drive.

the_pwner224 7y ago
Seems more like an issue with Windows and its ecosystem of nonfree software. On most of the Unix-like distros, the maintainers fetch & compile the applications that they make available in the repositories. They can provide a few packages for the various Qt libs, and add these as dependencies to the hundreds/thousands of programs that use Qt. The Qt libs are only downloaded once regardless of whether you have 1 or 20 end-user Qt applications. Dynamic loading and library updates aren't an issue since the distro maintainers recompile all the Qt-dependent applications whenever Qt has a major update. Older versions can be kept around for programs that haven't been updated in a long time (e.g. I have Qt4 installed on my system as a dependency even though Qt5 has been out for a long time), so there's little extra burden on developers. And with the exception of a few nonfree programs, the entire system works with one system-wide copy of any library. Of course that doesn't fix the issue for Windows/macOS users, but there's an obvious and proven solution which works, and if main reason it doesn't work for Windows/macOS is because most developers for those platforms restrict the users of their software using nonfree licensing, it only seems fair to blame those ecosystems and OSs instead of blaming Qt.
- guido_vongraum 7y ago
  Correct me if I'm wrong, but Windows ecosystem doesn't forbid e.g. Java applications to use the same system-wide JRE, which has to be installed once, manually. It would be a nightmare if every Java app installed its own copy of JRE. Still can happen, like in case of Processing, but that's more of an exception.
  - jcelerier 7y ago
    > Correct me if I'm wrong, but Windows ecosystem doesn't forbid e.g. Java applications to use the same system-wide JRE, which has to be installed once, manually. It would be a nightmare if every Java app installed its own copy of JRE. Still can happen, like in case of Processing, but that's more of an exception. uh... you were right in 2005. Nowadays the standard is for every app to ship its JRE - having to have to install a system wide JRE is part of the stuff that gave Java such a bad and bloaty reputation.
geezerjay 7y ago
> I believe 50MB is an exaggeration, but not too far-fetched one. That's quite an inelegant way to state that you know you've made a false claim but yet you still stick by it.
- guido_vongraum 7y ago
  In the light of 290MB of scattered DLLs mentioned above, I believe that this is more than elegant way to advocate the guy who made this false claim - if you read carefully enough, you'll notice that it wasn't me. Care to check?

the_pwner224 7y ago

Seems more like an issue with Windows and its ecosystem of nonfree software. On most of the Unix-like distros, the maintainers fetch & compile the applications that they make available in the repositories. They can provide a few packages for the various Qt libs, and add these as dependencies to the hundreds/thousands of programs that use Qt. The Qt libs are only downloaded once regardless of whether you have 1 or 20 end-user Qt applications. Dynamic loading and library updates aren't an issue since the distro maintainers recompile all the Qt-dependent applications whenever Qt has a major update. Older versions can be kept around for programs that haven't been updated in a long time (e.g. I have Qt4 installed on my system as a dependency even though Qt5 has been out for a long time), so there's little extra burden on developers. And with the exception of a few nonfree programs, the entire system works with one system-wide copy of any library. Of course that doesn't fix the issue for Windows/macOS users, but there's an obvious and proven solution which works, and if main reason it doesn't work for Windows/macOS is because most developers for those platforms restrict the users of their software using nonfree licensing, it only seems fair to blame those ecosystems and OSs instead of blaming Qt.

guido_vongraum 7y ago
Correct me if I'm wrong, but Windows ecosystem doesn't forbid e.g. Java applications to use the same system-wide JRE, which has to be installed once, manually. It would be a nightmare if every Java app installed its own copy of JRE. Still can happen, like in case of Processing, but that's more of an exception.
- jcelerier 7y ago
  > Correct me if I'm wrong, but Windows ecosystem doesn't forbid e.g. Java applications to use the same system-wide JRE, which has to be installed once, manually. It would be a nightmare if every Java app installed its own copy of JRE. Still can happen, like in case of Processing, but that's more of an exception. uh... you were right in 2005. Nowadays the standard is for every app to ship its JRE - having to have to install a system wide JRE is part of the stuff that gave Java such a bad and bloaty reputation.

geezerjay 7y ago

> I believe 50MB is an exaggeration, but not too far-fetched one. That's quite an inelegant way to state that you know you've made a false claim but yet you still stick by it.

guido_vongraum 7y ago
In the light of 290MB of scattered DLLs mentioned above, I believe that this is more than elegant way to advocate the guy who made this false claim - if you read carefully enough, you'll notice that it wasn't me. Care to check?