6 ms·

I am always in awe of these guys just for the sheer dedication. This is what, 12 years? And at least as far as I've seen they've been consistently active throug

by trotsky 13y ago

I am always in awe of these guys just for the sheer dedication. This is what, 12 years? And at least as far as I've seen they've been consistently active through it or at least it's never seemed dead. Yet they're still a good chunk away from an initial release milestone. I remember some folks used to rave about BeOS that's seldom been matched, but daaamn it had to have really been something to keep people going 12 years and several more to ship. I wonder who owns the intellectual property rights these days, or if there is something unsolvable about the licensed components. I know Jean-Louis Gassée is a notorious asshole at times, but it really seems like somebody should just give the code to these guys. It's not like they're ever going to market it again.

asiekierka 13y ago
They don't really need the code at this point anymore. They have as much BeOS compatibility as they'd get nowadays... now they're focusing on driver compatibility, porting more recent software to it and finally moving to GCC4 rather than BeOS's GCC2.95, IIRC. Also, more architectures.
ZenoArrow 13y ago
AFAIK, the intellectual property rights are owned by a Japanese company called Access. The IP isn't needed anymore. There's only one key feature holding back the first beta release, and that's a stable set of package management tools. Every other key component is in place.
- pifflesnort 13y ago
  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 13y 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 13y 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 13y 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 13y 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?

by trotsky 13y ago

asiekierka 13y ago

They don't really need the code at this point anymore. They have as much BeOS compatibility as they'd get nowadays... now they're focusing on driver compatibility, porting more recent software to it and finally moving to GCC4 rather than BeOS's GCC2.95, IIRC. Also, more architectures.

ZenoArrow 13y ago

AFAIK, the intellectual property rights are owned by a Japanese company called Access. The IP isn't needed anymore. There's only one key feature holding back the first beta release, and that's a stable set of package management tools. Every other key component is in place.

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