5 ms·

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

> 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.
  - ZenoArrow 14y ago
    >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. It's really not. Imagine a file system where all the "real" file locations are hidden, and the visible file structure just symlinks to these "real" locations. Practically no overhead at all. There will be a minor performance hit with uncompressing files before starting a program, but that's about all. > 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. My point was in terms of usability. The average user does not care about dependencies, nor do they need to care about them, even when using a package manager. > The OS vendors provide stable API/ABIs and comprehensive base system libraries, which means they don't need a UNIX package manager at all. That only works when all applications are written using those standard libraries, and that doesn't always happen, even on OSX. Why punish software developers for wanting to use libraries that better suit their needs? >a system that was originally built as a successor to the original Mac OS. The system was not built as a successor to the original Mac OS. The BeOS team were led by ex-Mac people, granted, but when it came to OS design they took ideas from many places, not just MacOS. As I've said before, the idea behind BeOS was to look to the future, not to be tied to the past.
msie 14y ago
Completely agree. It seems people who have no problem with Linux package management are bringing over the same problems to what should be a non-programmer-friendly system.
- derleth 14y ago
  > a non-programmer-friendly system. 'Non-programmer-friendly' like how MS-DOS was non-programmer-friendly with its memory models and lack of multitasking, or like how AS/400 was non-programmer-friendly with you choice of RPG or COBOL, or do you actually think that making something friendly for non-programmers automatically makes it non-friendly for programmers?
  - msie 13y ago
    Sorry, I meant user-friendly, where the user is not a programmer. Actually, making a package system friendly for users will make it friendly for a lot of programmers too - who are also users (and don't feel like wrestling with package systems too).

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.
- ZenoArrow 14y ago
  >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. It's really not. Imagine a file system where all the "real" file locations are hidden, and the visible file structure just symlinks to these "real" locations. Practically no overhead at all. There will be a minor performance hit with uncompressing files before starting a program, but that's about all. > 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. My point was in terms of usability. The average user does not care about dependencies, nor do they need to care about them, even when using a package manager. > The OS vendors provide stable API/ABIs and comprehensive base system libraries, which means they don't need a UNIX package manager at all. That only works when all applications are written using those standard libraries, and that doesn't always happen, even on OSX. Why punish software developers for wanting to use libraries that better suit their needs? >a system that was originally built as a successor to the original Mac OS. The system was not built as a successor to the original Mac OS. The BeOS team were led by ex-Mac people, granted, but when it came to OS design they took ideas from many places, not just MacOS. As I've said before, the idea behind BeOS was to look to the future, not to be tied to the past.

msie 14y ago

Completely agree. It seems people who have no problem with Linux package management are bringing over the same problems to what should be a non-programmer-friendly system.

derleth 14y ago
> a non-programmer-friendly system. 'Non-programmer-friendly' like how MS-DOS was non-programmer-friendly with its memory models and lack of multitasking, or like how AS/400 was non-programmer-friendly with you choice of RPG or COBOL, or do you actually think that making something friendly for non-programmers automatically makes it non-friendly for programmers?
- msie 13y ago
  Sorry, I meant user-friendly, where the user is not a programmer. Actually, making a package system friendly for users will make it friendly for a lot of programmers too - who are also users (and don't feel like wrestling with package systems too).