5 ms·

I've used Linux primarily since Debian potato, but the great wizards have not yet convinced me that the tree, starting at the holy / and a system with binaries,

by dusted 5y ago

I've used Linux primarily since Debian potato, but the great wizards have not yet convinced me that the tree, starting at the holy / and a system with binaries, their data and their libraries spread throughout the system is a wiser way than each partition an island, and each program living with all it needs in its own folder. I have heard the arguments but I have learned nothing.

approxim8ion 5y ago
Each program in Windows does not live with all its needs in its own folder though. Some store some of their stuff in the installation directory, others in AppData, others in ProgramData, others in the User's home folder (C:/<username/...) and so on.
- dusted 5y ago
  I've got lots of programs that are entirely self-contained and the folder can simply be moved to a new computer and it "just works", they include all the data files and dll's they want, and they keep their user-data under their own directory too, which is exactly how I want it for a _PERSONAL_ computer.
  - approxim8ion 5y ago
    That's fine. But it's not really a standard. Just an approach, and not one that is guaranteed to work unless that's an explicit goal for the program involved. Tbf, you can do the same thing on Linux with AppImages.
    - dusted 5y ago
      You can do the same with normal linux programs too, mine work fine, but the insistence of pulling apart a program and spread throughout the filesystem is in my opinion misunderstood. Sure, it made sense when it was introduced, for the reasons it was introduced, mainly, that drives were so small that you had to. There are very very few cases today where your program and it's accompanying files are so large that they cannot be expected to live on only a single disk.
      - smashed 5y ago
        Splitting app binaries that can be easily redownloaded from configs and user data makes a lot of sense. Also caches that can be deleted and rebuilt.
dTal 5y ago
Well, you're conflating two things there - a unified filesystem starting at /, and the pattern of organization that puts all runnable binaries into one location. The filesystem, on unix-like systems, is a namespace that contains every resource on the system (everything is a file). / is the root of the namespace. There is no good reason for a particular physical disk used to store some data to be at the root of the namespace; it's an implementation detail, and maybe not even the correct implementation detail. You might want to back a particularly weighty location with a larger disk, or a faster disk, or you might even want to run your system entirely off NFS. The filesystem abstracts all that away from applications. You can arrange your data physically however you like, and with a few lines in fstab, only the lowest levels of the OS need to know about it. You can also change all this on the fly. Contrast with Windows, where running out of space on disk C - THE disk, decided at installation and forever unchangeable - is a catastrophe, and there's no way of moving a weighty program to another disk without "reinstalling" it.
salamandersauce 5y ago
The advantage IMO is that programs don't care what physical drive they are on. On the Windows side I've run into a few that refuse to be installed on anything BUT C: even if D: or E: is a perfectly good or maybe even the same HDD.
skocznymroczny 5y ago
As mostly a Windows user, I like the macOS approach. Applications go to /Applications/, application data go to ~/Library/Application Support, settings go to ~/Library/Preferences. Installing an application is mostly done by drag and dropping to Application directory. To delete an app, just delete it from Applications directory.
thesuperbigfrog 5y ago
You should take a look at GoboLinux: https://gobolinux.org/ https://gobolinux.org/ "GoboLinux is a modular Linux distribution: it organizes the programs in your system in a new, logical way. Instead of having parts of a program thrown at /usr/bin, other parts at /etc and yet more parts thrown at /usr/share/something/or/another, each program gets its own directory tree, keeping them all neatly separated and allowing you to see everything that's installed in the system and which files belong to which programs in a simple and obvious way."

by dusted 5y ago

approxim8ion 5y ago

Each program in Windows does not live with all its needs in its own folder though. Some store some of their stuff in the installation directory, others in AppData, others in ProgramData, others in the User's home folder (C:/<username/...) and so on.

dusted 5y ago
I've got lots of programs that are entirely self-contained and the folder can simply be moved to a new computer and it "just works", they include all the data files and dll's they want, and they keep their user-data under their own directory too, which is exactly how I want it for a _PERSONAL_ computer.
- approxim8ion 5y ago
  That's fine. But it's not really a standard. Just an approach, and not one that is guaranteed to work unless that's an explicit goal for the program involved. Tbf, you can do the same thing on Linux with AppImages.
  - dusted 5y ago
    You can do the same with normal linux programs too, mine work fine, but the insistence of pulling apart a program and spread throughout the filesystem is in my opinion misunderstood. Sure, it made sense when it was introduced, for the reasons it was introduced, mainly, that drives were so small that you had to. There are very very few cases today where your program and it's accompanying files are so large that they cannot be expected to live on only a single disk.
    - smashed 5y ago
      Splitting app binaries that can be easily redownloaded from configs and user data makes a lot of sense. Also caches that can be deleted and rebuilt.

dTal 5y ago

Well, you're conflating two things there - a unified filesystem starting at /, and the pattern of organization that puts all runnable binaries into one location. The filesystem, on unix-like systems, is a namespace that contains every resource on the system (everything is a file). / is the root of the namespace. There is no good reason for a particular physical disk used to store some data to be at the root of the namespace; it's an implementation detail, and maybe not even the correct implementation detail. You might want to back a particularly weighty location with a larger disk, or a faster disk, or you might even want to run your system entirely off NFS. The filesystem abstracts all that away from applications. You can arrange your data physically however you like, and with a few lines in fstab, only the lowest levels of the OS need to know about it. You can also change all this on the fly. Contrast with Windows, where running out of space on disk C - THE disk, decided at installation and forever unchangeable - is a catastrophe, and there's no way of moving a weighty program to another disk without "reinstalling" it.

salamandersauce 5y ago

The advantage IMO is that programs don't care what physical drive they are on. On the Windows side I've run into a few that refuse to be installed on anything BUT C: even if D: or E: is a perfectly good or maybe even the same HDD.

skocznymroczny 5y ago

As mostly a Windows user, I like the macOS approach. Applications go to /Applications/, application data go to ~/Library/Application Support, settings go to ~/Library/Preferences. Installing an application is mostly done by drag and dropping to Application directory. To delete an app, just delete it from Applications directory.

thesuperbigfrog 5y ago

You should take a look at GoboLinux: https://gobolinux.org/ https://gobolinux.org/ "GoboLinux is a modular Linux distribution: it organizes the programs in your system in a new, logical way. Instead of having parts of a program thrown at /usr/bin, other parts at /etc and yet more parts thrown at /usr/share/something/or/another, each program gets its own directory tree, keeping them all neatly separated and allowing you to see everything that's installed in the system and which files belong to which programs in a simple and obvious way."