4 ms·

> A pseudo-filesystem is not high-overhead, unless you believe symlinks and pointers are high-overhead. Retrieving data from multiple on-disk compressed packag

> 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.
- pifflesnort 14y ago
  > 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. Are we talking about the same thing? It's a: - pseudofs - in userspace (IIRC) - which parses multiple archive files - and vends their contents as unionfs If this bought you anything at all useful, then maybe it would be worth all the complexity involved ... but it doesn't. > 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? It's not punishing developers. I've shipped software for Mac OS, Mac OS X and iOS for 15+ years, and believe me, being able to ship custom versions of libraries without having to deal with a package manager, library incompatibilities across applications, et, al, is an advantage. > The system was not built as a successor to the original Mac OS. The BeOS team were led by ex-Mac people, granted ... Led by ex-Mac people, including the former CEO of Apple. Targeted at the BeBox (PPC) and PPC Macs. Shopped to Apple for purchase. It was intended to be the successor to MacOS that Copland wasn't. > As I've said before, the idea behind BeOS was to look to the future, not to be tied to the past. Then maybe the new Haiku leadership should stop blindly copying what they're familiar with from Linux.
  - ZenoArrow 14y ago
    > Are we talking about the same thing? Admittedly I stopped following the development of Haiku and other alt operating systems over a year ago, so I couldn't say for sure whether the file system is in userspace. Doesn't seem like a good idea in the long run, hopefully it's just a temporary measure. > being able to ship custom versions of libraries without having to deal with a package manager, library incompatibilities across applications, et, al, is an advantage. But it's not always an advantage. Library duplication has a cost in terms of storage, plus the mechanism for program upgrades is clunkier than package managers allow (essentially either you have to download the full version of each program update or programs are bundled with their own package management mechanism, duplicating effort). > Led by ex-Mac people, including the former CEO of Apple. Targeted at the BeBox (PPC) and PPC Macs. Shopped to Apple for purchase. It was intended to be the successor to MacOS that Copland wasn't. Jean-Louis Gassée was a senior member at Apple, but never the CEO. BeOS was targetted at BeBox (their own machine) at first, then when that platform didn't take off it was targetted at PPC Macs, then x86 PCs. The purchase talks happened because the OS was struggling to gain market share. > Then maybe the new Haiku leadership should stop blindly copying what they're familiar with from Linux. As I said before, the design is quite different from Linux package managers, so Haiku are doing things their way.
rbanffy 14y ago
> 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 If you find it so depressing, instead of criticism, offer help. You are not helping. You are only offering your opinion.
- pifflesnort 14y ago
  > If you find it so depressing, instead of criticism, offer help. You are not helping. You are only offering your opinion. So you're saying that reasoned constructive criticism is not helping? You can't offer 'help' to people that don't want it. You'll waste your time and theirs.
  - rbanffy 14y ago
    All your criticism can be summed up by "it doesn't look like a Mac, therefore it's the wrong approach". Haiku is not a Mac. It's not Linux either, but, from a computer management perspective, tools like ports and yum solve many problems Macs also have. It's no coincidence each and every developer in my office who use a Mac also has either ports or brew installed. Dragging .app folders into icons does not solve every software management issue. If you need to keep your machine in a known and repeatable state, dragging icons will not take you far.
    - pifflesnort 13y ago
      What you're really saying is "I disagree with you, but I'm going to take a rhetorical roundabout in which I attempt to disqualify your argument by calling it 'not helpful'" > All your criticism can be summed up by "it doesn't look like a Mac, therefore it's the wrong approach". No, my criticism can be summed up like so: If you create unnecessary, reducible complexity, then add even more complexity on top of that to manage it, you're doing it wrong. > It's no coincidence each and every developer in my office who use a Mac also has either ports or brew installed. You're right. It's not. First of all, note what you said: every developer. Second of all, note what they're installing: UNIX software. UNIX software is a distribution mess, and it requires a UNIX package manager. If you don't create the mess in the first place, you don't need a package manager to manage it. Let third-party packaging systems deal with the UNIX packaging mess, and let engineers who need that software deal with the package managers needed to manage it. Net result: Your users (which includes engineers when they don't have their software development hat on) don't have to deal with the package management disaster unless they need to deal with UNIX software. QED.

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.

pifflesnort 14y ago
> 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. Are we talking about the same thing? It's a: - pseudofs - in userspace (IIRC) - which parses multiple archive files - and vends their contents as unionfs If this bought you anything at all useful, then maybe it would be worth all the complexity involved ... but it doesn't. > 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? It's not punishing developers. I've shipped software for Mac OS, Mac OS X and iOS for 15+ years, and believe me, being able to ship custom versions of libraries without having to deal with a package manager, library incompatibilities across applications, et, al, is an advantage. > The system was not built as a successor to the original Mac OS. The BeOS team were led by ex-Mac people, granted ... Led by ex-Mac people, including the former CEO of Apple. Targeted at the BeBox (PPC) and PPC Macs. Shopped to Apple for purchase. It was intended to be the successor to MacOS that Copland wasn't. > As I've said before, the idea behind BeOS was to look to the future, not to be tied to the past. Then maybe the new Haiku leadership should stop blindly copying what they're familiar with from Linux.
- ZenoArrow 14y ago
  > Are we talking about the same thing? Admittedly I stopped following the development of Haiku and other alt operating systems over a year ago, so I couldn't say for sure whether the file system is in userspace. Doesn't seem like a good idea in the long run, hopefully it's just a temporary measure. > being able to ship custom versions of libraries without having to deal with a package manager, library incompatibilities across applications, et, al, is an advantage. But it's not always an advantage. Library duplication has a cost in terms of storage, plus the mechanism for program upgrades is clunkier than package managers allow (essentially either you have to download the full version of each program update or programs are bundled with their own package management mechanism, duplicating effort). > Led by ex-Mac people, including the former CEO of Apple. Targeted at the BeBox (PPC) and PPC Macs. Shopped to Apple for purchase. It was intended to be the successor to MacOS that Copland wasn't. Jean-Louis Gassée was a senior member at Apple, but never the CEO. BeOS was targetted at BeBox (their own machine) at first, then when that platform didn't take off it was targetted at PPC Macs, then x86 PCs. The purchase talks happened because the OS was struggling to gain market share. > Then maybe the new Haiku leadership should stop blindly copying what they're familiar with from Linux. As I said before, the design is quite different from Linux package managers, so Haiku are doing things their way.

rbanffy 14y ago

> 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 If you find it so depressing, instead of criticism, offer help. You are not helping. You are only offering your opinion.

pifflesnort 14y ago
> If you find it so depressing, instead of criticism, offer help. You are not helping. You are only offering your opinion. So you're saying that reasoned constructive criticism is not helping? You can't offer 'help' to people that don't want it. You'll waste your time and theirs.
- rbanffy 14y ago
  All your criticism can be summed up by "it doesn't look like a Mac, therefore it's the wrong approach". Haiku is not a Mac. It's not Linux either, but, from a computer management perspective, tools like ports and yum solve many problems Macs also have. It's no coincidence each and every developer in my office who use a Mac also has either ports or brew installed. Dragging .app folders into icons does not solve every software management issue. If you need to keep your machine in a known and repeatable state, dragging icons will not take you far.
  - pifflesnort 13y ago
    What you're really saying is "I disagree with you, but I'm going to take a rhetorical roundabout in which I attempt to disqualify your argument by calling it 'not helpful'" > All your criticism can be summed up by "it doesn't look like a Mac, therefore it's the wrong approach". No, my criticism can be summed up like so: If you create unnecessary, reducible complexity, then add even more complexity on top of that to manage it, you're doing it wrong. > It's no coincidence each and every developer in my office who use a Mac also has either ports or brew installed. You're right. It's not. First of all, note what you said: every developer. Second of all, note what they're installing: UNIX software. UNIX software is a distribution mess, and it requires a UNIX package manager. If you don't create the mess in the first place, you don't need a package manager to manage it. Let third-party packaging systems deal with the UNIX packaging mess, and let engineers who need that software deal with the package managers needed to manage it. Net result: Your users (which includes engineers when they don't have their software development hat on) don't have to deal with the package management disaster unless they need to deal with UNIX software. QED.