Haiku: Making Things Difficult Because We Can

Although the volunteers and modestly paid developers are working hard to make Haiku a finished product, they are pointlessly working harder to port applications then should be necessary.

Specifically... developers are having to not only port over applications, which is a difficult enough task already... but to also make sure that when the apolications are ported.... they point to specific paths in the system that have the .self directory embedded within.

To be absolutely clear...no other Posix based operating system throws this unnecessary hurdle upon anyone who wishes to compile applications. These markers are clearly designed to be tied to specific versions of Posix software.

If you have upgraded Ubuntu or Open Suse in the last 5 years... you will know issues with package versioning has been long resolved...its a non issue now.

Yet the Haiku developers insist that these porting shackles are somehow better.

Anyone that has experience and puts thought into this knows its a grand waste of time.

The arrogance of the developers who insist this approach is somehow "the right way" coupled with a staunch adherence to this poorly thought out strategy is worthy of anyone-who-has-donated-to-the project's wrath and anger.

Because the difficulty serves to keep a useable Haiku off of user's computers DUE TO THE LACK OF A FULL SUITE OF APPLICATIONS THAT SHOULD OTHERWISE BE AVAILABLE.

The breakage to otherwise working Haikuware software evidences the unnecessary additional shackles that make the porting process even more difficult. What is worthy of outrage is that it is unnecessary.

Haiku has MUCH BIGGER BUGS TO SQUASH.

IS THERE A REASON TO waste time and money fixing problems we created outselves?

NO. THERE IS NO REASON.

Haiku lacks shared memory. This is why we don't have the big name open source applications.

BUT WE WON'T GET TO THE BIG ISSUES ANY TIME SOON IF WE KEEP DRINKING THE PACKAGE MANAGER KOOL AID.

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.

WHY HAIKU HAS NO USEFUL APPLICATIONS

Its been clear since at least mid 2013 that Haiku is hopelessly dysfunctional. However, there are a few people involved with the project that are genuinely good people.

But there a lot of people with clout in the project that just don't give a shit if they destroy other people's work. 

NOTE: MOST OF THE ISSUES DISCUSSED HERE CAN BE REMEDIED BY UNINSTALLING APP_SERVER FROM THE SYSTEM AND BY USING A 64 BIT VERSION OF HAIKU WITH THE LATEST VERSION OF GCC ONLY. 

Applications previously built for BEOS, that should work, do not any more. We don't have the source code for some of these applications. And for the applications that we have source code for, it is a giant waste of time to repackage applications because Haiku developers created a package manager that broke library pathing and made the file system read only.

There are a number of issues that resulted from the changes brought into Haiku with package management. It is a combination of:

A. Superfluous changes to the system unnecessary for package management
B. Flawed responses by core developers to requests to fix the circumstances
C. Haiku, Inc.'s refusal to act
D. Resulting formidable barriers to effective application porting development
E. Resulting lack of end user applications

All of these factors have resulted in effective contempt by Haiku, Inc. against its own community.

When the community raises the issues, they are not only ignored, but also they are accused of trolling. If anyone rebuts the flawed statements, they get banned from the mailing list. Clearly the hard coded path statement is flawed.

All of the now-broken applications were built prior to Haiku Inc.'s unnecessary and disruptive changes. A few years ago, a bug report was filed (pertaining to YAB) about the breakage caused by the disruptive changes. The report was ignored and the user later chastised. 

The contempt is clear because Haiku, Inc. could have made a few minor changes to remedy the situation without breaking the package manager. But instead of doing that, claims were made that "hard coded paths are broken by design." And this false claim was made by the same people who planned on using hard coded paths in their package building system.

It is clear they just didn't care that they broke numerous applications at Haikuware.
The core developers know how Haiku handles library dependencies when an application is executed. Yet they ask for statistics - some argument dreamed up in the "Haiku spin room."
Instead of statistics, lets talk about how applications work. So there won't be a misunderstanding. :-)

Right now Haiku does use "hard code paths" to find dependent libraries. Specifically, the library directory paths are embedded in applications built by Haikuporter and in some that come with the system. Some of the paths are even for non-existent directories. For example, libGL.so has a path to /home/builder.

It is noteworthy that Haiku Porter applications will never be able to work properly without using "hard coded paths." Haiku Porter applications are built in such a way that the location oft he library path is not predictable. The path contains a variable (the package name and version) and stored in the /packages/.self ... $PACKAGE-VERSION directory structure. In fact, all of the packages that are integrated into the package manager use the /packages/.self ... $PACKAGE-VERSION directory structure.

Even if this were to change, they still would use "hard coded paths" because of limitations placed upon Haiku's ability to find dependent libraries at run time. These limitations were put in place by Haiku, Inc.
Applications with dependent libraries can find the libraries at launch time by two different methods:

A.) The application has a hard coded path embedded in it, pointing to the dependent library  

example: 0x0000000f (RPATH) Library rpath: [/packages/gettext-0.19.2-1/.self/lib:/packages/ncurses-5.9-10/.self/develop/lib:/packages/libiconv-1.13.1-6/.self/develop/lib]

B.) The system pathing mechanism will search all of the specified directory paths for libraries.

In Haiku, the directory path settings are controlled by /boot/system/boot/SetupEnvironment.
This file is read only and cannot be modified by the end user, or application developer.

.profile broken by Haiku

This is unusual because most systems will allow its end users and developers to add a directory to a file so that applications can find their dependency libraries. Usually this is done by adding $PATH entries to a file called .profile. In Haiku, this file is located in /boot/home.

Unfortunately for Haiku users and developers, directory entries (for libraries) entered into /boot/home/.profile are ignored by the system pathing mechanism. So the end user has no way to change the system to tell the application where to find the library it needs to run.

Haiku has only provided one directory to end users to place dependency libraries that don't have the "hard coded path" embedded in the application. End users that want to use Haikuware applications are forced to place dependent libraries in /boot/home/config/non-packaged/lib, as it is the only writable path listed /boot/system/boot/SetupEnvironment. 

Users Forced to Use non-packaged/lib

If you thought editing that file would solve the problem, it won't. End users and application developers can't edit that either.

Placing a library in /boot/home/config/non-packaged/lib will only work if there is no hard coded path embedded in the Haikuware application.

Two of the three additional paths provided in /boot/system/boot/SetupEnvironment cannot be written to unless a .hpkg is used:
A. /boot/home/config/lib (doesn't exist by default)
B. /boot/system/lib (User cannot write to this at all)
C. /boot/system/non-packaged/lib (Makes the user push shift if a GUI is used to place the files)

If a Haikuware application has a "hard coded path" to find libraries and it is not "/boot/home/config/non-packaged/lib" the package won't work without significant additional work that would have to be done by the end user:

First, they would have to run readelf -d to find out where the application is looking for libraries.
.

Secondly, if the path does not exist, they will have to create the directory. (If the directory is withing the read only portion of the file system, they won't be able to create the directory, and won't be able to use the package. Probably a rare circumstance.)
.

Thirdly, they will have to manually place (or symlink) all of the dependent libraries in the directory path the application is looking for libraries in.

.
However, this is not just about libraries. 

.

It is likely that many Haikuware applications will be a POSIX application, and many POSIX applications use hard coded configuration settings that cannot be avoided without having to make unreasonable changes to the source code. And even if they tried, there will be times in which there is no documentation to tell developers what to change these paths to.

*****************************************************************************

Note that embedding a variable in the code (found in finddirectories.h) that uses a system defined variable in Haiku IS ONLY RELEVANT AFTER THE PROGRAM IS EXECUTED.

This is what they mean when they talk about not using "hard coded paths." In some ways it is cross talk that is more effective in silencing decent rather than fixing some serious issues that plague Haiku.

When one ports over very large applications with thousands of files included, this is a nightmare. It is near impossible for anyone to find all of the hard coded paths or path variables in unfamiliar code and convert them to Haiku's nomenclature. Its simply too time consuming.

Most of the programs people want to use (such as Firefox) are very large and unfamiliar source code pools. I assume this is why there is a symlinked the /tmp directory that comes with Haiku.

These disruptive changes to the system had nothing to do with the package manager being able to run properly.

What almost no one else seems to realize is that the system has numerous problems building packages without the artificial problems created by the package manager already. Package building is a house of cards - large desirable applications have numerous dependencies. It is tedious under the best of conditions. However, Haiku presents additional issues to the developer that must be overcome.

Some of the issues are present because we either have not implemented the feature, refuse to implement the feature, or cannot implement the feature.

• Some of the issues are our own creation.

• Some of the issues are standard porting issues related to Haiku's identity.

• Right now, no tool set is adequate to deal with all of the issues Haiku has with building a significant number of packages. And it is because of the mire creating choices that have been made by core developers.

The requirement to tediously make sure that all the Haiku Porter packages have a hard coded path (relative or not) is just one more thing that makes package creation in Haiku too tedious for most people's taste. So we end up having not many packages.
When an application is ported over to Haiku, all of these changes have to be maintained and patches reapplied with newer versions, if a patch is not accepted upstream. Unfortunately this happens fairly often, to the point that Haiku has more forks than can be found at a satanist's BSD convention.


To develop packages for Haiku, a developer will have issues with:

• Memory limitations that require special configuration options just to compile.

•  Header content (missing variables we have refused to include in headers because they aren't in the POSIX standards, yet still widespread in applications end users want to use)

• Header clash (Two pathed headers with same variable)

• Unique directory structure

• File system does not support hard links.

•  Some applications, such as Samba, expect to have read access to certain system folders.

•  Compiled applications expecting the system to provide memory or threads in a way that Haiku does not provide

•   Library differences (no lmath, lnetwork instead of locket, etc.)

•  Code changes to map system directories to code (temporary files from /tmp to /boot/system/cache, etc.)

All of the above force developers to patch repetitively and tediously. To the point that no one does it all. Add the inability to control library paths, the issues are too numerous to overcome.

**THE RESULT IS THAT WE HAVE MADE THE PROCESS TOO TEDIOUS AND TIME CONSUMING TO ALLOW FOR SIGNIFICANT PACKAGE CREATION**
THE CURRENT SITUATION IS DETRIMENTAL TO THE FUTURE OF HAIKU.

The "/boot/home/config/non-packaged/lib" path did not exist when the now broken Haikuware applications were made. Responses from the core developers chide application porters for not being psychic.

Using a hard coded library path to launch an application is not "broken by design" - rather its simply an option. However, I am certain that any system that requires all of its packages to use hard coded paths for libraries, is a system that requires its developers to do too much work.

Library path "hard coding" isn't something a developer goes out of his way to add to the source code. Instead, it is something that a developer has to go out of his way to add or remove from the source code. Most of the time, the compiler tools and source code will behave in one of numerous ways. Without tedious nursing of source code:

• Some of the packages will be compiled against libraries from /boot/system and end up with the .self hard coded path. (see example above)

• Some of the packages will be compiled against libraries from .self and end up with the .self hard coded path.

• Some of the packages will be compiled against libraries from /boot/system and have no hard coded path

• Some of the packages will be compiled against libraries from .self and have no hard coded path

Three of the four possible outcomes above will result in mismatches between the library link and library path.  As a result, things won't work right because the application will run against a library it wasn't compiled with.

Often times people will re-brand the reasonable complaint about the application porting workload such as to confuse average users. They misunderstand the issues and cast their proposals into requests to "turn Haiku into Linux." Part of the contempt takes place when core developers don't correct these statements.

A package manager is supposed to install or uninstall compiled code from a system.

• No sane person would expect the addition of the package manager to result in so much breakage to existing applications.

• No sane person would expect the addition of the package manager to result in the creation of additional formidable barriers to current package creation.

Important Moments in the Haiku Operating System's Path to Suckage

Haiku's file system creator says hard links are unnecessary:
From: http://comments.gmane.org/gmane.os.haiku.devel/12076:

Pier Luigi Fiorini <pierluigi.fiorini@...> wrote:
> 2009/11/18 Ingo Weinhold <ingo_weinhold@...>
> > Haiku's BFS implementation is on-disk compatible with Be's and to 
> > my
> > knowledge it's a limitation of the on-disk structure design that 
> > prevents
> > hard links from being possible.

Exactly.

> For what it's worth, it's probably time to avoid R5 compatibility on 
> some
> things - I know it's not scheduled until R2 but sometimes I think 
> Haiku is
> still cloning and old '90s OS...

Because hard links didn't exist in 1990?
The fact is that BFS is the only file system delivering the 
functionality we need for Haiku. And it doesn't make any sense to me to 
break compatibility just for hard links -- there are way more reasons 
to develop a new file system, but that will take some time.

It would make more sense to have a read/write ReiserFS, or ext4, or 
btrfs, or XFS, or whatever file system port that you can use in that 
case. Beyond backups and VCS, hard links have no real use that I am 
aware of, anyway.

Bye,
   Axel.

*************************************************************

Yet when Python attempts to build its modules, it uses hard links, as reported back by the kernel log:

KERN: bfs: bfs_open_dir:1644: Not a directory
KERN: Last message repeated 83 times.
KERN: bfs: bfs_access:1516: Operation not allowed
KERN: bfs: bfs_open_dir:1644: Not a directory
KERN: Last message repeated 25 times.
KERN: bfs: bfs_access:1516: Operation not allowed

As a result, Python cannot be built natively in HaikuOS, as reported by the kernel during .py module builds:

**************************************************

Bad enough as it is already, requests for a writeable /usr directory were rejected...even the creation of a symlink to /usr was poo pooed:
From: http://www.freelists.org/post/haiku-development/RFC-usr-symlink,14
and http://www.freelists.org/post/haiku-development/usrbin,1

Rob Judd wrote:
> Until we go multi-user, could we have a symlink from /boot/system/bin to
> /usr/bin please? It would make porting apps that call /usr/bin/env a
> whole lot easier.

Even with multi user, there will never be a /usr directory in Haiku.
Porting is not just recompiling, and it deserves a bit more attention
(like to put the settings into the right place, or use the native Media
Kit instead of porting G-Streamer as well).

Bye,
   Axel.

***************************************************************

On Thu, Oct 10, 2013 at 9:21 PM, Alexander von Gluck IV
<kallisti5@xxxxxxxxxxx> wrote:
>
> mmadia pointed out this was discussed previously:
> http://www.freelists.org/post/haiku-development/usrbin

OK, this has inspired a rant:

I'm sorry guys, all the arguments in that thread are unconvincing, and
amount to nothing more than "Haiku does this a certain way, and that
is it, no ifs, ands or buts and no compromising."

Having to "port" shell scripts which use /usr/bin/env is a big waste
of time. Don't you purists think we have enough work already???

Haiku is not Unix, but it has a very Unix-like shell and terminal, and
has many Unix commands, and is pretty darn POSIX compliant. Lots and
lots and lots and lots of shell scripts use the /usr/bin/env "trick."
It works on Linux, Mac OS X, FreeBSD and probably just about every
other system except plain Windows (I'm sure it works in Cygwin.)

You really want to argue against ONE SIMPLE SYMLINK??? In reality no
one will ever notice it and, frankly, it can even be automatically
hidden in Tracker if you guys are so bothered by it. As if adding usr
will confuse people as compared to all the other Unix like directories
in the Haiku root: bin, boot, dev, etc, tmp and var!!!

In case you can't tell, I support adding this symlink, because I'm a
pragmatist, and like to get things done, and having shell scripts not
work because of this has annoyed me again and again and again and
again on Haiku. No upstream would accept a patch which changed this,
so it just means a permanent "Haiku branch" of whatever software you
are talking about. That is stupid.

And I don't want to hear "well just add it to your own Haiku." No,
that is not a solution. Because inevitably I will expect other people
to make use of things I've made, and it is stupid to have to tell them
"If you are on Haiku, please create a symlink from /usr to
/boot/system, before you can actually use my script."

Lastly, let's address the argument that this "degrades the purity of
the Haiku file system layout." You mean the layout that has been
completely changed around and made quite complicated by package
management? The layout that already has FIVE other three-letter
Unix-derived directories at the root? Sorry that argument is now out
too.

In case you can't tell, this is one of those things that has really
annoyed me and touches on overall issues of Haiku trying to be
different so much that it becomes damaging.

-- 
Regards,
Ryan

This was eventually not approved.


********************************************************************************

Python is important because it is a major dependency for applications desktop users want to use. If you want to build anything of any significance, such as Firefox or any of the other major open source applications, you need a working Python installation that is newer than the version currently supplied (2.6).

********************************************************************************

The above issues make building Python much more difficult than it needs to be (so much work it is impractical. Even if the work were done, it would be unmaintainable for all practical purposes, as explained in the discussions above.