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.
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.
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.
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.
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:
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:
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.
*****************************************************************************
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.
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
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.
No comments:
Post a Comment