3 ms·

The opposite problem, which comes from relying on a package manager + repo, is that anything you want to do that isn't in the repo (more up to date stuff, obscu

The opposite problem, which comes from relying on a package manager + repo, is that anything you want to do that isn't in the repo (more up to date stuff, obscure stuff) is a giant pain in the ass to get. You end up having to compile it yourself from source (and it isn't like build environments don't have their own compatibility issues), or use something like PPAs (assuming they exist for what you want), or manually doing the job of a package manger to adapt a foreign package. Static executables and AppImage make this a lot better, but they are not the convention so they can't really be relied upon either. Good luck getting a package manager to install anything to a non-standard location like a removable disk. When it comes right down to it, I prefer the Windows convention of installers and zips to package management and all its limitations. Precisely because things like "Another example were various driver tweaks/hacks or anything else a gamer or power user might want to do." are easily available with that model. Distributing software on Windows is something anyone can do very easily, without relying on a third party package repo or maintainer. 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.

solarkraft 6y ago
> 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.
GoblinSlayer 6y ago
Microsoft figured out how to do easy side loading on linux: https://github.com/dotnet/core/blob/master/release-notes/3.1/3.1.9/3.1.9.md https://github.com/dotnet/core/blob/master/release-notes/3.1... But deb and rpm packages are just compressed tar archives, unpacking should work just like for tar.gz.
- AnIdiotOnTheNet 6y ago
  Sometimes yes, other times there are conflicts because a lot of libraries are not forward compatible (glibc for instance) and different distributions have different conventions for library naming and paths. In my experience, you usually have to use a lot of LD_LIBRARY_PATH and related shenanigans to get anything working and it will still break when interfacing with software that uses a different version of GLIBC.
  - GoblinSlayer 6y ago
    People somehow manage to compile code in a way that works everywhere. I guess the trick is to compile against debian stable.

solarkraft 6y ago

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

GoblinSlayer 6y ago

Microsoft figured out how to do easy side loading on linux: https://github.com/dotnet/core/blob/master/release-notes/3.1/3.1.9/3.1.9.md https://github.com/dotnet/core/blob/master/release-notes/3.1... But deb and rpm packages are just compressed tar archives, unpacking should work just like for tar.gz.

AnIdiotOnTheNet 6y ago
Sometimes yes, other times there are conflicts because a lot of libraries are not forward compatible (glibc for instance) and different distributions have different conventions for library naming and paths. In my experience, you usually have to use a lot of LD_LIBRARY_PATH and related shenanigans to get anything working and it will still break when interfacing with software that uses a different version of GLIBC.
- GoblinSlayer 6y ago
  People somehow manage to compile code in a way that works everywhere. I guess the trick is to compile against debian stable.