On the contrary, we can and should blame Haiku. It wouldn’t take much to make the ‘beoscompatibility’ package mandatory, and make sure that Haiku include legacy and native libraries so that the hundreds of available BeOS and Haiku applications would ‘just work’ seamlessly. BeOS went out of its way to make sure 3rd party apps work, Haiku seemingly not. Without a package manager to grab dependencies, Haiku should include the most common application dependent libraries, not let ordinary users try to find them.
Name a single user to me, that wants to spend hours downloading and unpacking all these packages:
Or one day download x package because application y needs it, the next day download package b because application c needed it - and so on and so on. Total non-sense!
Don’t like being a fatty? Offer an optional package like Haikuware does that combines all HaikuPorts’ files into one installer.
I would much rather add 240.5 mb to Haiku’s girth to have an Operating System that works out of the box with most software than answer hundreds of emails about why x,y, and z application doesn’t work, and where to get x,y and z library. Bandwidth and disk space are cheap these days, it isn’t 1999. If users prefer to download each package step by step, let them be miserable.
Perhaps mention in the docs (or add a symlink to the file in Haiku itself) that one should install this single Haiku Port package for BeOS/Haiku library compatibility/support. The user installs it, then watches as >90% of their present and future dependency problems disappear in one step - maybe Haiku will be ‘simple to use’ then.
The amount of native apps developed in the past few years, and especially since alpha 1, can be counted on the fingers of your two hands, and will likely remain that way until R1 and beyond. This should be reason enough to support legacy applications. Haiku even has problems including libraries for important native apps like WebPositive that it advertises and takes donations for. Then when you go to download it and run it, surprise, missing libraries.
Where will users look for Haiku files therefore? The User Docs & Google. It’s nice to have Haiku mention both BeBits and Haikuware as a source for Haiku software, but, isn’t it a contradiction in terms to make the ‘beoscompatibility’ package optional then?? Google will return page rank 6 websites BeBits and Haikuware. So, here we have Google and Haiku forwarding to websites that offer files that won’t run under Haiku because of missing oplibraries and an ‘optional’ compatibility package. As a new user, it would probably leave a bad taste in my mouth and scare me away from Haiku rather than attract me - even Linux fairs better in this topic’s regard. So, IMHO, I think Haiku should try a little harder to solve this problem - Haiku shouldn’t sabotage its future success. Applications pave the way to an Operating System’s success, not the other way around.
I guess this is when people start thinking hard about distros…
I started Haikuware in 2007. Back then, Haiku’s goal was to achieve ‘binary compatibility with BeOS R5.’ That meant, theoretically, that almost every application on Haikuware should have worked on R1. Somewhere along the line, the little description of what Haiku is that graces the top left side of their website, lost these words. I hope that it isn’t too late to fulfill these goals and reverse some of this damage.
When users and developers say, why does Haikuware have incompatible software on their website, don’t they care? Ask not Haikuware, but Haiku Inc.
I aplogize in advance if I offended anyone, it’s not my intention. I know Haiku isn’t done and is a great group of volunteers. Given the time, energy and resources I put into Haikuware and BeBits, I hope my frustration is understood.
re: Humdinger: “were just grabbed” - actually, it was a daunting task importing and scouring the internet for over 2500 files. At least Haiku users have a reliable place to download applications to play with. I hope some users appreciate the service instead of complain all the time.