2 ms·

> Distributing software on Windows is something anyone can do very easily, without relying on a third party package repo or maintainer. Is that so? Last time I

> Distributing software on Windows is something anyone can do very easily, without relying on a third party package repo or maintainer. Is that so? Last time I checked you had to choose between 3 installation approaches and then choose a 3rd party installer (all of which have bad UX) and set that up. Fragmentation exists on Windows too, it's just internal. > However, what we should really be doing, in my opinion, is something like AppImage (or NeXT Application Directories , or RiscOS AppDirs, etc.) combined with a sandbox-by-default similar to what exists on mobile, but without pops or the ability for the application to tell when it has been denied a permission. You're probably taking about Flatpak and Snap. One has great marketing but is not usable for ethical/practical concerns while I haven't had a very good experience with with Flatpak (its "runtimes" are basically extra Linux distributions).

AnIdiotOnTheNet 6y ago
> Is that so? Last time I checked you had to choose between 3 installation approaches and then choose a 3rd party installer (all of which have bad UX) and set that up. Due to the convention of not relying on fixed-paths in Windows software, as well as Windows providing a stable base platform of common libraries, pretty much anyone can just compile a program and put it and its resources into a zip file. The vast majority of the software I install is distributed this way. > Fragmentation exists on Windows too, it's just internal. The fragmentation of Windows is orders of magnitude less than Linux. I can write software today that will work without modification even on versions of windows from 15 years ago without recompilation[0]. Occasionally there are minor incompatibilities between Windows versions and editions, but it isn't that way for most software. > You're probably taking about Flatpak and Snap. One has great marketing but is not usable for ethical/practical concerns while I haven't had a very good experience with with Flatpak (its "runtimes" are basically extra Linux distributions). No, I'm not. In my opinion Flatpak and Snap combine the worst of both worlds in that they still require repos and a special tool to manage them. I meant exactly what I said: AppDirs with default sandboxing. [0] Hell, thanks to WINE it will probably even work on Linux without recompilation.
- ubercow13 6y ago
  >I can write software today that will work without modification even on versions of windows from 15 years ago without recompilation On the other hand if my Windows app is complete in and of itself, but depends on a library which requires security updates, I will have to continuously release and distribute updates to it for the next 15 years (or however long it remains useful) even though the app itself is not changing. I'm currently working on a Windows plugin for an app, which requires linking to a ~20MB library, and also another library which in turn links to that same ~20MB library, but using an incompatible linker. The plugin is also for an application that uses that ~20MB library, distributed separately, and in turn many users install a standalone version of that library to use alongside the program. That's 4 copies of the library just for one application on Windows, and this library is common and most likely also distributed with many other apps on most users PCs. All of them will need separate updates.
  - AnIdiotOnTheNet 6y ago
    > On the other hand if my Windows app is complete in and of itself, but depends on a library which requires security updates, I will have to continuously release and distribute updates to it for the next 15 years (or however long it remains useful) even though the app itself is not changing. Only if that library is not part of the base Windows platform, which already supplies a whole lot of things you'd typically need, cryptographic functions among them. So yeah, if you depend on things that aren't part of the base platform it is your responsibility to update them. Or, and this is equally imporntant, not update them if doing so breaks your application. If you only depend on the platform then you don't really need to worry about it except in the rare case of an ABI break. By contrast, breaking user space ABI on Linux is tradition, and there isn't really any such thing as a stable and consistent set of libraries you can depend on as a platform because of the ludicrous level of fragmentation. > I'm currently working on a Windows plugin for an app, which requires linking to a ~20MB library, and also another library which in turn links to that same ~20MB library, but using an incompatible linker. The plugin is also for an application that uses that ~20MB library, distributed separately, and in turn many users install a standalone version of that library to use alongside the program. That's 4 copies of the library just for one application on Windows, and this library is common and most likely also distributed with many other apps on most users PCs. All of them will need separate updates. I'm curious what this library could be. At that size and level of commonness, I can only imagine that it is Qt or GTK, or some other "portable" platform layer.

AnIdiotOnTheNet 6y ago

> Is that so? Last time I checked you had to choose between 3 installation approaches and then choose a 3rd party installer (all of which have bad UX) and set that up. Due to the convention of not relying on fixed-paths in Windows software, as well as Windows providing a stable base platform of common libraries, pretty much anyone can just compile a program and put it and its resources into a zip file. The vast majority of the software I install is distributed this way. > Fragmentation exists on Windows too, it's just internal. The fragmentation of Windows is orders of magnitude less than Linux. I can write software today that will work without modification even on versions of windows from 15 years ago without recompilation[0]. Occasionally there are minor incompatibilities between Windows versions and editions, but it isn't that way for most software. > You're probably taking about Flatpak and Snap. One has great marketing but is not usable for ethical/practical concerns while I haven't had a very good experience with with Flatpak (its "runtimes" are basically extra Linux distributions). No, I'm not. In my opinion Flatpak and Snap combine the worst of both worlds in that they still require repos and a special tool to manage them. I meant exactly what I said: AppDirs with default sandboxing. [0] Hell, thanks to WINE it will probably even work on Linux without recompilation.

ubercow13 6y ago
>I can write software today that will work without modification even on versions of windows from 15 years ago without recompilation On the other hand if my Windows app is complete in and of itself, but depends on a library which requires security updates, I will have to continuously release and distribute updates to it for the next 15 years (or however long it remains useful) even though the app itself is not changing. I'm currently working on a Windows plugin for an app, which requires linking to a ~20MB library, and also another library which in turn links to that same ~20MB library, but using an incompatible linker. The plugin is also for an application that uses that ~20MB library, distributed separately, and in turn many users install a standalone version of that library to use alongside the program. That's 4 copies of the library just for one application on Windows, and this library is common and most likely also distributed with many other apps on most users PCs. All of them will need separate updates.
- AnIdiotOnTheNet 6y ago
  > On the other hand if my Windows app is complete in and of itself, but depends on a library which requires security updates, I will have to continuously release and distribute updates to it for the next 15 years (or however long it remains useful) even though the app itself is not changing. Only if that library is not part of the base Windows platform, which already supplies a whole lot of things you'd typically need, cryptographic functions among them. So yeah, if you depend on things that aren't part of the base platform it is your responsibility to update them. Or, and this is equally imporntant, not update them if doing so breaks your application. If you only depend on the platform then you don't really need to worry about it except in the rare case of an ABI break. By contrast, breaking user space ABI on Linux is tradition, and there isn't really any such thing as a stable and consistent set of libraries you can depend on as a platform because of the ludicrous level of fragmentation. > I'm currently working on a Windows plugin for an app, which requires linking to a ~20MB library, and also another library which in turn links to that same ~20MB library, but using an incompatible linker. The plugin is also for an application that uses that ~20MB library, distributed separately, and in turn many users install a standalone version of that library to use alongside the program. That's 4 copies of the library just for one application on Windows, and this library is common and most likely also distributed with many other apps on most users PCs. All of them will need separate updates. I'm curious what this library could be. At that size and level of commonness, I can only imagine that it is Qt or GTK, or some other "portable" platform layer.