5 ms·

I'm familiar with the proposal -- it has all the same problems of Linux package managers, but then they bolted on an even more complex, error prone, and high-o

I'm familiar with the proposal -- it has all the same problems of Linux package managers, but then they bolted on an even more complex, error prone, and high-overhead virtual file system to present different views of the package graph. The problem is the legacy UNIX practice of splatting files all over the drive and having an unstable dependency graph. Fix that, and you don't need a UNIX package manager.

ZenoArrow 14y ago
High-overhead based on what, the compressed packages? I'm guessing you're a fan of the OSX .dmg approach... which also supports file compression. The 'unstable dependency graph' is anything but, instead it's quite straightforward to manage. To explain, think of PATH variables in most modern operating systems. You have a bunch of paths to folders that state where to find your applications, libraries, image assets, etc... Programs that rely on dependencies search through these folders for what they need. This also allows flexibility for file system layout, as you can add additional 'watched folders'. Furthermore, you don't need to install or uninstall a program in the same way, so this 'splatting files all over the drive' can also be avoided.
- pifflesnort 14y ago
  > High-overhead based on what, the compressed packages? I'm guessing you're a fan of the OSX .dmg approach... which also supports file compression. DMG is an archive distribution format. The packaging pseudo-filesystem is going to be sitting between the user/kernel, interdicted through a file, and then through a file system, for all access to all installed software. Think FUSE. > The 'unstable dependency graph' is anything but, instead it's quite straightforward to manage. To explain, think of PATH variables in most modern operating systems. First of all, you just called PATH straight-forward. Try explaining PATH to the average desktop or mobile OS user, and then try explaining why this is better than the App Store or drag-installs. Second of all, the problem isn't the PATH thing. The problem is a huge dependency graph of non-ABI stable libraries and packages that are comprised of a ton of files splatted over the disk. If you get rid of the non-ABI-stable libraries, and don't splat your files everywhere, you don't need some crazy pseudofs-based package manager to manage your software. Problem solved. No package management (in the Linux sense) required. Isn't it a good thing to remove unneeded, reducible complexity?
  - ZenoArrow 14y ago
    >The packaging pseudo-filesystem is going to be sitting between the user/kernel, interdicted through a file, and then through a file system, for all access to all installed software. A pseudo-filesystem is not high-overhead, unless you believe symlinks and pointers are high-overhead. >First of all, you just called PATH straight-forward. Try explaining PATH to the average desktop or mobile OS user, and then try explaining why this is better than the App Store or drag-installs. Here's the thing: an 'average user' doesn't care about 'a ton of files splatted over the disk' either. How many Windows users bother even looking in the Windows directory or Program Files directory? The 'a ton of files splatted over the disk' issue is only an issue for power users, who like to feel in complete control of their system. As for App Stores, they're just like a traditional package manager but with a simpler UI and the option to buy software before downloading it. If you're familiar with Ubuntu, compare Synaptic with the Ubuntu Software Centre? See a difference beyond the cosmetic layer? Now compare the Ubuntu Software Centre with the Apple App Store, can you see a difference beyond the cosmetic layer? I've got a strong feeling of déjà-vu discussing this, are you a Haiku-OS.org forum member?
    - pifflesnort 14y ago
      > A pseudo-filesystem is not high-overhead, unless you believe symlinks and pointers are high-overhead. Retrieving data from multiple on-disk compressed package archives and presenting them as a union pseudofs is a heck of a lot more overhead than hitting the file system directly. > As for App Stores, they're just like a traditional package manager but with a simpler UI and the option to buy software before downloading it. Actually, they're nothing like a traditional UNIX package manager, because they don't handle dependencies. They're application bundles (ala Mac OS X) with a store front-end. The OS vendors provide stable API/ABIs and comprehensive base system libraries, which means they don't need a UNIX package manager at all. It's really depressing to see Haiku come so close to completion, only to have project direction taken over at the very end by Linux developers (literally, that's their day job), who are bringing Linux ideals to a system that was originally built as a successor to the original Mac OS.
      - 14y ago

ZenoArrow 14y ago

High-overhead based on what, the compressed packages? I'm guessing you're a fan of the OSX .dmg approach... which also supports file compression. The 'unstable dependency graph' is anything but, instead it's quite straightforward to manage. To explain, think of PATH variables in most modern operating systems. You have a bunch of paths to folders that state where to find your applications, libraries, image assets, etc... Programs that rely on dependencies search through these folders for what they need. This also allows flexibility for file system layout, as you can add additional 'watched folders'. Furthermore, you don't need to install or uninstall a program in the same way, so this 'splatting files all over the drive' can also be avoided.

pifflesnort 14y ago
> High-overhead based on what, the compressed packages? I'm guessing you're a fan of the OSX .dmg approach... which also supports file compression. DMG is an archive distribution format. The packaging pseudo-filesystem is going to be sitting between the user/kernel, interdicted through a file, and then through a file system, for all access to all installed software. Think FUSE. > The 'unstable dependency graph' is anything but, instead it's quite straightforward to manage. To explain, think of PATH variables in most modern operating systems. First of all, you just called PATH straight-forward. Try explaining PATH to the average desktop or mobile OS user, and then try explaining why this is better than the App Store or drag-installs. Second of all, the problem isn't the PATH thing. The problem is a huge dependency graph of non-ABI stable libraries and packages that are comprised of a ton of files splatted over the disk. If you get rid of the non-ABI-stable libraries, and don't splat your files everywhere, you don't need some crazy pseudofs-based package manager to manage your software. Problem solved. No package management (in the Linux sense) required. Isn't it a good thing to remove unneeded, reducible complexity?
- ZenoArrow 14y ago
  >The packaging pseudo-filesystem is going to be sitting between the user/kernel, interdicted through a file, and then through a file system, for all access to all installed software. A pseudo-filesystem is not high-overhead, unless you believe symlinks and pointers are high-overhead. >First of all, you just called PATH straight-forward. Try explaining PATH to the average desktop or mobile OS user, and then try explaining why this is better than the App Store or drag-installs. Here's the thing: an 'average user' doesn't care about 'a ton of files splatted over the disk' either. How many Windows users bother even looking in the Windows directory or Program Files directory? The 'a ton of files splatted over the disk' issue is only an issue for power users, who like to feel in complete control of their system. As for App Stores, they're just like a traditional package manager but with a simpler UI and the option to buy software before downloading it. If you're familiar with Ubuntu, compare Synaptic with the Ubuntu Software Centre? See a difference beyond the cosmetic layer? Now compare the Ubuntu Software Centre with the Apple App Store, can you see a difference beyond the cosmetic layer? I've got a strong feeling of déjà-vu discussing this, are you a Haiku-OS.org forum member?
  - pifflesnort 14y ago
    > A pseudo-filesystem is not high-overhead, unless you believe symlinks and pointers are high-overhead. Retrieving data from multiple on-disk compressed package archives and presenting them as a union pseudofs is a heck of a lot more overhead than hitting the file system directly. > As for App Stores, they're just like a traditional package manager but with a simpler UI and the option to buy software before downloading it. Actually, they're nothing like a traditional UNIX package manager, because they don't handle dependencies. They're application bundles (ala Mac OS X) with a store front-end. The OS vendors provide stable API/ABIs and comprehensive base system libraries, which means they don't need a UNIX package manager at all. It's really depressing to see Haiku come so close to completion, only to have project direction taken over at the very end by Linux developers (literally, that's their day job), who are bringing Linux ideals to a system that was originally built as a successor to the original Mac OS.
    - 14y ago