8 ms·

It's absolutely bizarre that the developers have adopted the Linux idea of package management, including shared library dependency hell that requires maintainin

It's absolutely bizarre that the developers have adopted the Linux idea of package management, including shared library dependency hell that requires maintaining the dependency graph in lockstep. You only need a traditional UNIX package manager if you have traditional UNIX packages -- splatting files all over the file system, providing unstable ABI/API, etc. The OS is basically ready to release now, and instead of focusing on polish, they're bringing over one of the worst features of Linux. You'd think they'd at least borrow from the modern app store idea of "packages". They're actually implementing package management as a paid project. I'm seriously annoyed that my donation to Haiku is being spent on that, rather than on things that would actually matter to existing desktop users coming from Mac OS X. It seems that Haiku has floundered, largely due to the take-over of Linux-centric developers after the original project leader (Michael Phipps) left in 2009. Michael kept the project very focused on BeOS R1, and now it's all over the map and pulling in the very ideas from Linux that BeOS and MacOS were built in opposition to.

ZenoArrow 14y ago
The package management system planned for Haiku is somewhat different from traditional Linux package managers, and supports the "packages" concept. If you'd like to read more, please feel free: https://www.haiku-os.org/blog/mmadia/2012-08-20_brief_summary_haikus_package_management https://www.haiku-os.org/blog/mmadia/2012-08-20_brief_summar...
- pifflesnort 14y ago
  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?
trotsky 14y ago
Since you seem rather familiar, I've always wanted to ask what the story with the widgets/theme is. I have nothing but respect for all the work that's been done. But the UI really stands out as distinctively from a very specific era and just doesn't feel very appealing now. So I'm curious what the primary driver is there. Faithful recreation as a core value? Sort of a badge of honor type thing for the BeOS faithful? Lack of ui/ux contributors? Or just lower on the priority list? I'm not knocking it, rationally i don't have a problem with it, but at the same time i can't imagine i'd be up for using it as a main os.
- ZenoArrow 14y ago
  The UI was one of the few components carried over from BeOS, as it was open-sourced (OpenTracker): http://en.wikipedia.org/wiki/OpenTracker http://en.wikipedia.org/wiki/OpenTracker There have been some refinements made to the UI during the Haiku era (such as Stack and Tile windows and vector icons by default), but has otherwise remained stable. What's the main reason behind that? It's not a priority for R1 (the first stable release). No reason it can evolve in time. What in particular do you dislike about the look? Should point out the deskbar can be moved around to be more 'Start Menu'-like if you so wish. http://www.haiku-os.org/docs/userguide/en/deskbar.html http://www.haiku-os.org/docs/userguide/en/deskbar.html
  - trotsky 14y ago
    Oh, I don't mean app positions or use patterns or anything like that. I mean toolkit widgets like sliders, buttons, chrome, window manager elements, that kind of thing. And for the record i feel the exact same way about plain xtk, old style gtk/gnome and probably win2k and earlier if i saw em. I had to go and look at a bunch of screenshots to come up with an answer besides just the "feel". I think a big part of it is the heavy reliance on thin embossed/3d borders and lines, no rounded or softened elements, the limited palette use in core elements, no rich gradients or transparencies. I didn't realize it at all until i made the list, but I guess a big part of it is the look of a toolkit/window manager that was built on top of a 3d api and compositor. I guess the gpu industry norms are a huge barrier for anyone on an alternate path.
- 14y ago
doktrin 14y ago
> The OS is basically ready to release now, and instead of focusing on polish, they're bringing over one of the worst features of Linux. Frankly, I've always thought of package managers (both at the OS and library / dependency level) to be among my favorite features in any ecosystem, be it Arch, Ubuntu, Ruby or Node.js. Even in a world where spatting files all over the system, managing complex PATH variables & dependency graphs is unnecessary, some manner of centralized package manager / installer has a very real place. Even something as fairly straightforward as pulling down a set of binaries can be made simpler when handled by a package manager, and doubly so when compiling from source. Futzing around with make files is certainly very, very low on my to-do list. It's possible I'm missing something fundamental, here, in which case please help me out. What is your ideal-world vision of how an OS should handle installing & managing binaries & dependencies?
- pifflesnort 14y ago
  > It's possible I'm missing something fundamental, here, in which case please help me out. What is your ideal-world vision of how an OS should handle installing & managing binaries & dependencies? Drag (anywhere) to install. Drag to the trash remove. Add an optional App Store UI to purchase/download/update applications and call it a day. This doesn't work for software build/distributed via the UNIX model, but that's the whole point -- if you don't use the UNIX approach to distributing end-user software, you don't create a problem that requires a package manager to solve.
  - doktrin 14y ago
    > Drag (anywhere) to install. Drag to the trash remove. Add an optional App Store UI to purchase/download/update applications and call it a day. So, that's obviously the approach Apple's taken, and it has numerous strengths. "Installing" & removing .app files is quite simple, but that's of course not the whole story. Both application support files as well as (IIRC) cache files linger around the OS until removed manually. This is typically NBD (well, no huge deal), but it deserves mention. Managing remnant traces of .app files requires either manually navigating the OS and deleting files, or using 3rd party apps. It's worth noting that these 3rd party apps basically do what package managers do, except only at the uninstall stage. More importantly, when I use OSX, I most certainly am also variously using brew & make to install various pieces of software not packaged as .app binaries. While in a somewhat ideal world it's possible to envision a scenario where all necessary binaries for a given OS are neatly packaged in a preferred format, that seems unrealistic. If I'm still, in 2013, installing really standard tools with a Linux-style package manager on OSX, it's safe to say there's no way I could expect all my requisite applications to be available for a nascent OS with a fraction of its userbase like Haiku. Lastly, even assuming all binaries that could possibly be executed on a given system are packaged as .app file (equivalents), I frankly wouldn't mind having a package manager available to install (copy), manage, organize & remove my binaries (including support files). A package manager is a ultimately a tool of convenience, it's simply more convenient when dealing with a more classical *nix path / dependency model.
cjsthompson 13y ago
I think you're absolutely right : package management is a symptom of a developper-centric OS. I've packaged several hundreds of apps for Linux and have been using it almost exclusively since 1997. And the least I can say is that it's a bloody unholy mess. The latest joke/failure in Linux is the packaging of TeX on Fedora which uses (if my memory serves me right) over 3,000 packages! Many developpers just do what they feel like doing and often disregard standards because a lot of them think they know better ( also known as the "not invented here" syndrome ). How many times did I send patches upstream to fix an standards issue ( such as a missing pkgconfig file ) and some arrogant developper who thinks he knows better rejects it. And when someone comes in and tries to consolidate the OS a bit (what the systemd guys are trying to do) a horde of reactionary users start trolling the hell out of them. As far as Haiku, I think the plan with the package manager is to only use it to update the base OS. Apps would still be installed by unzipping them in an appropriate place. At least I hope so. If not it will be as you say yet another exotic UNIX variant. Unfortunately, there also have been talks of replacing the BeOS API with Qt.

ZenoArrow 14y ago

The package management system planned for Haiku is somewhat different from traditional Linux package managers, and supports the "packages" concept. If you'd like to read more, please feel free: https://www.haiku-os.org/blog/mmadia/2012-08-20_brief_summary_haikus_package_management https://www.haiku-os.org/blog/mmadia/2012-08-20_brief_summar...

pifflesnort 14y ago
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?

trotsky 14y ago

Since you seem rather familiar, I've always wanted to ask what the story with the widgets/theme is. I have nothing but respect for all the work that's been done. But the UI really stands out as distinctively from a very specific era and just doesn't feel very appealing now. So I'm curious what the primary driver is there. Faithful recreation as a core value? Sort of a badge of honor type thing for the BeOS faithful? Lack of ui/ux contributors? Or just lower on the priority list? I'm not knocking it, rationally i don't have a problem with it, but at the same time i can't imagine i'd be up for using it as a main os.

ZenoArrow 14y ago
The UI was one of the few components carried over from BeOS, as it was open-sourced (OpenTracker): http://en.wikipedia.org/wiki/OpenTracker http://en.wikipedia.org/wiki/OpenTracker There have been some refinements made to the UI during the Haiku era (such as Stack and Tile windows and vector icons by default), but has otherwise remained stable. What's the main reason behind that? It's not a priority for R1 (the first stable release). No reason it can evolve in time. What in particular do you dislike about the look? Should point out the deskbar can be moved around to be more 'Start Menu'-like if you so wish. http://www.haiku-os.org/docs/userguide/en/deskbar.html http://www.haiku-os.org/docs/userguide/en/deskbar.html
- trotsky 14y ago
  Oh, I don't mean app positions or use patterns or anything like that. I mean toolkit widgets like sliders, buttons, chrome, window manager elements, that kind of thing. And for the record i feel the exact same way about plain xtk, old style gtk/gnome and probably win2k and earlier if i saw em. I had to go and look at a bunch of screenshots to come up with an answer besides just the "feel". I think a big part of it is the heavy reliance on thin embossed/3d borders and lines, no rounded or softened elements, the limited palette use in core elements, no rich gradients or transparencies. I didn't realize it at all until i made the list, but I guess a big part of it is the look of a toolkit/window manager that was built on top of a 3d api and compositor. I guess the gpu industry norms are a huge barrier for anyone on an alternate path.
14y ago

doktrin 14y ago

> The OS is basically ready to release now, and instead of focusing on polish, they're bringing over one of the worst features of Linux. Frankly, I've always thought of package managers (both at the OS and library / dependency level) to be among my favorite features in any ecosystem, be it Arch, Ubuntu, Ruby or Node.js. Even in a world where spatting files all over the system, managing complex PATH variables & dependency graphs is unnecessary, some manner of centralized package manager / installer has a very real place. Even something as fairly straightforward as pulling down a set of binaries can be made simpler when handled by a package manager, and doubly so when compiling from source. Futzing around with make files is certainly very, very low on my to-do list. It's possible I'm missing something fundamental, here, in which case please help me out. What is your ideal-world vision of how an OS should handle installing & managing binaries & dependencies?

pifflesnort 14y ago
> It's possible I'm missing something fundamental, here, in which case please help me out. What is your ideal-world vision of how an OS should handle installing & managing binaries & dependencies? Drag (anywhere) to install. Drag to the trash remove. Add an optional App Store UI to purchase/download/update applications and call it a day. This doesn't work for software build/distributed via the UNIX model, but that's the whole point -- if you don't use the UNIX approach to distributing end-user software, you don't create a problem that requires a package manager to solve.
- doktrin 14y ago
  > Drag (anywhere) to install. Drag to the trash remove. Add an optional App Store UI to purchase/download/update applications and call it a day. So, that's obviously the approach Apple's taken, and it has numerous strengths. "Installing" & removing .app files is quite simple, but that's of course not the whole story. Both application support files as well as (IIRC) cache files linger around the OS until removed manually. This is typically NBD (well, no huge deal), but it deserves mention. Managing remnant traces of .app files requires either manually navigating the OS and deleting files, or using 3rd party apps. It's worth noting that these 3rd party apps basically do what package managers do, except only at the uninstall stage. More importantly, when I use OSX, I most certainly am also variously using brew & make to install various pieces of software not packaged as .app binaries. While in a somewhat ideal world it's possible to envision a scenario where all necessary binaries for a given OS are neatly packaged in a preferred format, that seems unrealistic. If I'm still, in 2013, installing really standard tools with a Linux-style package manager on OSX, it's safe to say there's no way I could expect all my requisite applications to be available for a nascent OS with a fraction of its userbase like Haiku. Lastly, even assuming all binaries that could possibly be executed on a given system are packaged as .app file (equivalents), I frankly wouldn't mind having a package manager available to install (copy), manage, organize & remove my binaries (including support files). A package manager is a ultimately a tool of convenience, it's simply more convenient when dealing with a more classical *nix path / dependency model.

cjsthompson 13y ago

I think you're absolutely right : package management is a symptom of a developper-centric OS. I've packaged several hundreds of apps for Linux and have been using it almost exclusively since 1997. And the least I can say is that it's a bloody unholy mess. The latest joke/failure in Linux is the packaging of TeX on Fedora which uses (if my memory serves me right) over 3,000 packages! Many developpers just do what they feel like doing and often disregard standards because a lot of them think they know better ( also known as the "not invented here" syndrome ). How many times did I send patches upstream to fix an standards issue ( such as a missing pkgconfig file ) and some arrogant developper who thinks he knows better rejects it. And when someone comes in and tries to consolidate the OS a bit (what the systemd guys are trying to do) a horde of reactionary users start trolling the hell out of them. As far as Haiku, I think the plan with the package manager is to only use it to update the base OS. Apps would still be installed by unzipping them in an appropriate place. At least I hope so. If not it will be as you say yet another exotic UNIX variant. Unfortunately, there also have been talks of replacing the BeOS API with Qt.