3 ms·

> 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 t

> 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.
  - ubercow13 6y ago
    >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. This is true but for apps where source code is available, it doesn't seem like that much of an impediment to keeping things working. I use various tools that haven't been updated for many years but have been easy to keep working as Linux userspace has changed. For closed-source things indeed it's different. >I'm curious what this library could be. The example was ffmpeg. You're right that there probably aren't that many examples of common libraries of that size. But Qt is a good example and why shouldn't it be reasonable to use it and not have a burden placed on me to provide security updates? If I am writing an app and want to use something like libcurl, I would prefer not to have the onus placed on me to monitor and distribute libcurl security updates for the rest of my life, especially if this is just a hobby project. Suddenly I am taking on the role and responsibility akin to a whole Linux distribution, and all because I wanted to write some silly little app. And even if I am that responsible, I as a user have to count on all the developers of apps I'm using to be just as responsible themselves. I mostly have no way to know whether they are, unlike the situation for example as a Debian user where they have a known track record and I can have some level of confidence.
rstuart4133 6y ago
> I can write software today that will work without modification even on versions of windows from 15 years ago without recompilation. I had a Windows user loudly say this in a room while I was in it. It's true Microsoft does a reasonable job of keeping one programs working. Not perfect, I've had many stand alone programs fail to run in "compatibility mode". It's a commendable effort nonetheless. But in contrast, Linus has kept his "don't break userspace" promise damned near perfectly. So upon hearing someone claim yet again how much better Windows does this than Linux, laptop running some 2020 debian stable and a 64 bit Linux kernel, download Debian potato (circa 2000) and expand to a directory on machine running the latest Linux 64 (potato is 32 bit only), chrooted into it, apt install whatever, and showed him it all just works. I could do that with any distribution on my modern Debian laptop.
- AnIdiotOnTheNet 6y ago
  > But in contrast, Linus has kept his "don't break userspace" promise damned near perfectly. Yes, because Linus gets it. The people behind the userspace of desktop Linux really really don't though. If I want to write a Linux program that will work in 20 years without recompilation I can only depend on the kernel. Case in point: > download Debian potato (circa 2000) and expand to a directory on machine running the latest Linux 64 (potato is 32 bit only), chrooted into it, apt install whatever, and showed him it all just works. You basically had to swap out the entire userspace to do that because ABI compatibility outside of the kernel is practically nonexistant.

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.
- ubercow13 6y ago
  >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. This is true but for apps where source code is available, it doesn't seem like that much of an impediment to keeping things working. I use various tools that haven't been updated for many years but have been easy to keep working as Linux userspace has changed. For closed-source things indeed it's different. >I'm curious what this library could be. The example was ffmpeg. You're right that there probably aren't that many examples of common libraries of that size. But Qt is a good example and why shouldn't it be reasonable to use it and not have a burden placed on me to provide security updates? If I am writing an app and want to use something like libcurl, I would prefer not to have the onus placed on me to monitor and distribute libcurl security updates for the rest of my life, especially if this is just a hobby project. Suddenly I am taking on the role and responsibility akin to a whole Linux distribution, and all because I wanted to write some silly little app. And even if I am that responsible, I as a user have to count on all the developers of apps I'm using to be just as responsible themselves. I mostly have no way to know whether they are, unlike the situation for example as a Debian user where they have a known track record and I can have some level of confidence.

rstuart4133 6y ago

> I can write software today that will work without modification even on versions of windows from 15 years ago without recompilation. I had a Windows user loudly say this in a room while I was in it. It's true Microsoft does a reasonable job of keeping one programs working. Not perfect, I've had many stand alone programs fail to run in "compatibility mode". It's a commendable effort nonetheless. But in contrast, Linus has kept his "don't break userspace" promise damned near perfectly. So upon hearing someone claim yet again how much better Windows does this than Linux, laptop running some 2020 debian stable and a 64 bit Linux kernel, download Debian potato (circa 2000) and expand to a directory on machine running the latest Linux 64 (potato is 32 bit only), chrooted into it, apt install whatever, and showed him it all just works. I could do that with any distribution on my modern Debian laptop.

AnIdiotOnTheNet 6y ago
> But in contrast, Linus has kept his "don't break userspace" promise damned near perfectly. Yes, because Linus gets it. The people behind the userspace of desktop Linux really really don't though. If I want to write a Linux program that will work in 20 years without recompilation I can only depend on the kernel. Case in point: > download Debian potato (circa 2000) and expand to a directory on machine running the latest Linux 64 (potato is 32 bit only), chrooted into it, apt install whatever, and showed him it all just works. You basically had to swap out the entire userspace to do that because ABI compatibility outside of the kernel is practically nonexistant.