4 ms·

> It'd be nice if Windows had as nice of a filesystem organization story as any linux distro. ...are you serious? There's a lot of words to describe the Linux

> It'd be nice if Windows had as nice of a filesystem organization story as any linux distro. ...are you serious? There's a lot of words to describe the Linux filesystem organization and 'nice' is definitely not one of them. Windows file hierarchy has some problems to be sure, but at least it doesn't scatter every application's files all over the hierarchy and require a specialized tool and database to track which ones belong to which applications.

cycloptic 6y ago
It's popular for Linux distributions to have a scattered hierarchy with a package manager, but it certainly isn't a requirement. Take a look at AppImages.
- AnIdiotOnTheNet 6y ago
  AppImages are pretty great, when they actually exist for your applications. It is exceptionally disingenuous, however, to suggest that the existence of some AppImages invalidates the file hierarchy organization problems of any distro. You might have been better to point out the existence of GoboLinux, but that is but one not very popular distro among many.
  - cycloptic 6y ago
    Please do not baselessly accuse me of being "disingenuous," I'm trying to help you. If you won't use GoboLinux or ask packagers to make AppImages for the apps you want then I don't know what to say, those are solutions to your problem. If you're saying you want all other distributions to be like GoboLinux, I doubt that would happen because that comes with its own set of other problems. Edit: You can do some pretty interesting things here with Nix/Guix too although that still requires a package manager. The reason I said AppImages is because that's currently the best method that doesn't require any package manager at all.
    - AnIdiotOnTheNet 6y ago
      > Please do not baselessly accuse me of being "disingenuous," I'm trying to help you. Help me with what exactly? Am I in need of saving for my denial of The One True UNIX Way? > If you won't use GoboLinux or ask packagers to make AppImages for the apps you want then I don't know what to say, those are solutions to your problem. There are lots of reasons I don't use GoboLinux, not the least of which is that I don't think compiling applications from source is a reasonable application distribution method in 2021. As for asking application developers to make AppImages: why do you assume that I don't? Regardless, the point is that the "Linux filesystem organization story" referred to by the parent is neither GoboLinux nor a bunch of AppImages and you are being disingenuous to pretend otherwise. It's a tired old Linux Desktop evangelism tactic roughly equivalent to "well, Linux is just a kernel...", which is to say that the argument is that what Linux Desktop (and by extension its filesystem organization) is is so ill defined that it can be whatever you want it to be -- provided you write most of it yourself, from the kernel up, like Android. However there is a clear "way things are done" for the vast, vast majority of Linux distros and that is obviously what's being talked about here.
      - cycloptic 6y ago
        I haven't "pretended otherwise" or evangelized anything, please don't make these accusations at me. I can only offer you suggestions on what to do, I'm not going to argue about what the "right" way to do is as that's simply not interesting to me. The vast majority of Linux distributions may not do things the "right" way but they also support AppImages, so use that to your advantage. If you had no success in getting upstream to make AppImages then you'll have to make them yourself. It seems that's what a lot of flatpak and snap packagers ended up doing, just my observation. To put this another way: We can sit here making the same complaints about Ubuntu and RHEL that have been made for decades, but what's the point? Let's do something about it. And if that doing something means we turn the whole system into AppImages, then... what else would you really want? It sounds like your problem would then be solved.
        AnIdiotOnTheNet 6y ago
pizza234 6y ago
What do you refer, specifically? Based on "application's files all over the hierarchy" it seems you talk about configuration files (data files can be spread all over, in any operating system; binaries in Linux reside in a few directories (/opt and /usr)). If you refer to gconf/dconf, AFAIK they require a specialized tool but they're not scattered (you interact through the tool, after all, so they're centralized). Possibly you refer to the Freedesktop configuration files. Those are definitely scattered, and some concepts are very obscure (the defaults system is indeed terrible, as it's scattered, and it has different concepts of default). However, they don't require specialized tools - in my experience, they're always text files.
- AnIdiotOnTheNet 6y ago
  I mean literally the application and its files. A package for something like KeePassXC[0] places its assets, "shared" libraries, and binaries in disparate directories mixed with other applications binaries, assets, and libraries. [0] https://packages.ubuntu.com/groovy/amd64/keepassxc/filelist https://packages.ubuntu.com/groovy/amd64/keepassxc/filelist Configuration files are a whole 'nother garbage fire mess, but that's true in Windows too so whatever.
  - pizza234 6y ago
    ok, you're referring to package management. if you talk about configuration files, well behaved packages will differentiate removal and purge; the latter will remove configurations and data. > [0] https://packages.ubuntu.com/groovy/amd64/keepassxc/filelist https://packages.ubuntu.com/groovy/amd64/keepassxc/filelist what's wrong specifically with that? based on the list of files, the package is well-behaved, as it's placing the files in the expected locations (I personally didn't know about /usr/share/metainfo, but seems correct). also, it's not clear why the quotes in "shared" libraries; .so is a shared library extension, and it's proper design to make it available. apt takes care of those files, so there's no problem. how it handles the data files should be described in the scripts, but this is up to the package maintainer. Windows, for comparison, is hell, since applications install files pretty much where they want, and that's why Windows, in the long term, gets more polluted than Linux (worst offender - leftover DLL, which impact the system). OS X could be the good reference for your isolation standards, but keep in mind that that level of isolation prevents reuse, and indeed, the open source package management reference is Brew, which has its own rules.

cycloptic 6y ago

It's popular for Linux distributions to have a scattered hierarchy with a package manager, but it certainly isn't a requirement. Take a look at AppImages.

AnIdiotOnTheNet 6y ago
AppImages are pretty great, when they actually exist for your applications. It is exceptionally disingenuous, however, to suggest that the existence of some AppImages invalidates the file hierarchy organization problems of any distro. You might have been better to point out the existence of GoboLinux, but that is but one not very popular distro among many.
- cycloptic 6y ago
  Please do not baselessly accuse me of being "disingenuous," I'm trying to help you. If you won't use GoboLinux or ask packagers to make AppImages for the apps you want then I don't know what to say, those are solutions to your problem. If you're saying you want all other distributions to be like GoboLinux, I doubt that would happen because that comes with its own set of other problems. Edit: You can do some pretty interesting things here with Nix/Guix too although that still requires a package manager. The reason I said AppImages is because that's currently the best method that doesn't require any package manager at all.
  - AnIdiotOnTheNet 6y ago
    > Please do not baselessly accuse me of being "disingenuous," I'm trying to help you. Help me with what exactly? Am I in need of saving for my denial of The One True UNIX Way? > If you won't use GoboLinux or ask packagers to make AppImages for the apps you want then I don't know what to say, those are solutions to your problem. There are lots of reasons I don't use GoboLinux, not the least of which is that I don't think compiling applications from source is a reasonable application distribution method in 2021. As for asking application developers to make AppImages: why do you assume that I don't? Regardless, the point is that the "Linux filesystem organization story" referred to by the parent is neither GoboLinux nor a bunch of AppImages and you are being disingenuous to pretend otherwise. It's a tired old Linux Desktop evangelism tactic roughly equivalent to "well, Linux is just a kernel...", which is to say that the argument is that what Linux Desktop (and by extension its filesystem organization) is is so ill defined that it can be whatever you want it to be -- provided you write most of it yourself, from the kernel up, like Android. However there is a clear "way things are done" for the vast, vast majority of Linux distros and that is obviously what's being talked about here.
    - cycloptic 6y ago
      I haven't "pretended otherwise" or evangelized anything, please don't make these accusations at me. I can only offer you suggestions on what to do, I'm not going to argue about what the "right" way to do is as that's simply not interesting to me. The vast majority of Linux distributions may not do things the "right" way but they also support AppImages, so use that to your advantage. If you had no success in getting upstream to make AppImages then you'll have to make them yourself. It seems that's what a lot of flatpak and snap packagers ended up doing, just my observation. To put this another way: We can sit here making the same complaints about Ubuntu and RHEL that have been made for decades, but what's the point? Let's do something about it. And if that doing something means we turn the whole system into AppImages, then... what else would you really want? It sounds like your problem would then be solved.
      - AnIdiotOnTheNet 6y ago

pizza234 6y ago

What do you refer, specifically? Based on "application's files all over the hierarchy" it seems you talk about configuration files (data files can be spread all over, in any operating system; binaries in Linux reside in a few directories (/opt and /usr)). If you refer to gconf/dconf, AFAIK they require a specialized tool but they're not scattered (you interact through the tool, after all, so they're centralized). Possibly you refer to the Freedesktop configuration files. Those are definitely scattered, and some concepts are very obscure (the defaults system is indeed terrible, as it's scattered, and it has different concepts of default). However, they don't require specialized tools - in my experience, they're always text files.

AnIdiotOnTheNet 6y ago
I mean literally the application and its files. A package for something like KeePassXC[0] places its assets, "shared" libraries, and binaries in disparate directories mixed with other applications binaries, assets, and libraries. [0] https://packages.ubuntu.com/groovy/amd64/keepassxc/filelist https://packages.ubuntu.com/groovy/amd64/keepassxc/filelist Configuration files are a whole 'nother garbage fire mess, but that's true in Windows too so whatever.
- pizza234 6y ago
  ok, you're referring to package management. if you talk about configuration files, well behaved packages will differentiate removal and purge; the latter will remove configurations and data. > [0] https://packages.ubuntu.com/groovy/amd64/keepassxc/filelist https://packages.ubuntu.com/groovy/amd64/keepassxc/filelist what's wrong specifically with that? based on the list of files, the package is well-behaved, as it's placing the files in the expected locations (I personally didn't know about /usr/share/metainfo, but seems correct). also, it's not clear why the quotes in "shared" libraries; .so is a shared library extension, and it's proper design to make it available. apt takes care of those files, so there's no problem. how it handles the data files should be described in the scripts, but this is up to the package maintainer. Windows, for comparison, is hell, since applications install files pretty much where they want, and that's why Windows, in the long term, gets more polluted than Linux (worst offender - leftover DLL, which impact the system). OS X could be the good reference for your isolation standards, but keep in mind that that level of isolation prevents reuse, and indeed, the open source package management reference is Brew, which has its own rules.