Mystery Bugs and Unported Software

As has already been discovered and explained in the "forum post that they didn't want you to read".... chronic bugs in the linker has caused Kim to not be able to sucessfully build Java, a problem she posted about today in the forum.

Julian H also had inconsistent results trying to build libbe.so... but whilst trying to build it in Linux the problem was mysteriously gone. Hmmmm. Well them's the breaks when Haiku's linker has a serious unreported and uncorrected bug. All will seem to be great if the library is built in Linux.

However....the symboling difference will eventually rear its ugly head again when some software being built from source in Haiku attempts to link against it. And it will be quite a mystery. Well its not a mystery and hasn't been for quite some time.

The silly $30,000 suggested bounty for GoBe Productive backport is indeed a waste of money...not only for reasons stated today in the forum...but because it would be much more beneficial for Haiku (in general) if shared memory were fixed and if the kernel were developed to be robust enough to handle building applications like Open Office. But that will still be impossible while the linker that Ingo broke remains practically useless.

George Galloway

Recent Discussions on Haikuports No Word Processor!

As has been said for well over a year....and thoughly discussed in "the post they didn't want you to read" Haiku does not support shared memory, Haiku literally cannot build GTK applications. It also cannot build a version of Cairo that will build a version of Pango that Firefox requires. 

Haiku needs kernel work, but it will not be done. Haiku needs to be capable of building all its libraries within itself. Haiku needs to stick to one architecture so patches produce consistant results. It needs to be able to use up to date tools like GCC4 reliably. But it cannot.

And that is not even counting the poor read only design and poorly thought out and tedious design of Haikuports that places a library version in an unopportune location. It does not resolve issues with library versioning. That is what configure scripts are for.

Absolutely no reason anyone should have to maintain a broken and GTKless Abiword fork just for Haiku. Its stupid because its too much work for the maintainer who will probably never get his changes folded in. Porting and folding in is already is a lot of work.

But the decision makers at Haiku are stubbornly determined to keep Haiku broken. Maybe some cross compiling methods might provide a breakthrough...in the manner Tiltos showed its promise. But it had to full scale replace libraries that came with Haiku. But with the broken linker and unreliable symboling this might not even be an option any more.

When asked to implement shared memory, Axel and Ingo responded as if shared memory was improper...and now we are in the second rate application situation we are in.

So no, I don't believe the current leadership has the smallest chance of delivering a fully funtional BeOS replacement. Because the group doesn't have the knowledge to recognize when they are being told critical information.

There are numerous and complicated and near impossible to explain reasons why Richie Nhyus will not get his word processor any time soon. The reasons he won't are outlined in the post he deleted from the forum and that was saved and posted here. The same post he, Polkamandy and numerous others callously described as trolling.

How do you like that?

If You Want to Save BeOS

Go to haikuware.com and register your support for Senryu.

I screw around here some times. But this is drop dead serious.

I want a fully functional BeOS replacement.

Overall Haiku is disfunctional. Its stagnant.

No good suggestion escapes a denial from this group.

We have been brought the bad news: its package manager is designed to make it as difficult as possible to port open source applications people want to use.

There are serious flaws in the libraries, they have to be built in Linux. The linker is broken.

The Kernel, as good as it was made...has serious memory issues.

The Board won't remove themselves and developers refuse to fix most issues that are raised...and most of these issues are valid. Yet raising these issues only results in censorship. And Oliver's crockodile tears.

The only person close to legit to lead us to the promised land is a person who has done everything he could for the good of the community at all times. Period.

No, that's not me.

That is KARL VON DORFF.

No one paid him to care, that's just the way he was in the important position he was in.

He would be the perfect leader if he placed less importance on bounties. I do think payment is important though. So I'm not poo pooing bounties.

However, money can't buy solutions to practically unfixable problems. And all Haiku has managed to do is create unfixablle problems, at least within the confines of its social structure.

In contrast, Senryu offers a chance for the disenfranchised to become reenergized with a project that has a worthwhile goal.

So its time to move on and work within a structure that is most viable for BeOS' user's future. Because Haiku has proven it is not up to the task. Don't throw your time away. Work with a project with a future.

Folks, the only way we will get anywhere is if KARL steps up and saves the community. That's it.

There are talented committed people working on Haiku. But Jessica can only take Haiku so far.

NO PRESSURE KARL.

Priqueless CUPSless Printing

Kudos to the only developer with the balls to answer the question: a woman named Jessica. She tries her best and I respect that.

The only reason we don't have a descent modern printing system is because the developers have stupidly made parts of the system read only. Further, they have excluded the possibility of having certain directories exist on a haiku system.

Since no sane person wants to rewrite CUPS just for the above, let alone maintain yet another pointless fork with root cause as characterized as above, no one bothers.

This is why we are stuck with a crap print subsystem.