Free Hans Island from the Canadian oppression

Here you will find unbiased information about the territorial conflict between Denmark and Canada over Hans Island. Be sure to check our website from time to time, to get the latest information about the conflict.

Latest development: During the summer of 2010, a peaceful delegation of Danish citizens visited Hans Island. During their stay, the delegation build a small monument, using local rocks. The Canadian government, despite their territorial claims, failed to offer any emergency services to the group. In doing so, the lives of the participants was put in severe jeopardy, and only good fortune prevented any serious accidents.

Introduction
For many years now, the Canadian military has systematically invaded the Danish territory of Hans Island. In doing so, Canada have demonstrated a total disregard for international treaties. Despite repeated pleas for peace, Canada has not shown any remorse on the matter. Because of this, we demand that Canada is excluded from NATO, and apologize to the people of Denmark for their repeated offences.

The Canadian so-called free press, no doubt being manipulated by its government's lies, are playing down the repeated violations by the Canadian military, claiming that Hans Island is not important. Nothing could be further from the truth. Aside from the important wildlife on and around Hans Island, Hans Island plays an important part in the regional ownership of oil and gas reserves. Canada is therefore using Hans Island as an excuse for violating Denmark's legitimate claims for the natural resources in the area. This eagerness of Canada's part is no doubt due to a strong desire to explore the underground for resources, potentially contaminating a vast area of beautiful nature. Because Denmark is self-supplying with oil and natural gas, it is not necessary to sacrifice the precious tranquility of Hans Island for meager profit.

In the past, the area of present-day Canada has used as a platform for attacks by other countries; amongst others the United States, which resulted in the destruction of both historical landmarks and great works of art in the burning of Washington DC. Although the invading forces were forced back eventually, Canada's government has never given any official apology. This is the kind of irresponsible behaviour the Canadian gouvernment represents. If Canada's government is not shy of supporting attacks on superpowers such as the United States, what will prevent them from doing the same against the unarmed Hans Island?

Facts about the Canadian occupation of Hans Island

• No humans have lived on Hans Island since Canada first occupied it.
• The landscape of Hans Island has been barren, to say the least, since Canada first occupied it.
• Canadian military and state officials have frequently violated the Danish sovereignity at Hans Island.
• The Danish navy has suffered no casualties in the struggle for Hans Island. Canadian losses are unknown, but are at least equal, possibly higher.
• Canada has not yet used nuclear weapons against Denmark. Denmark has no nuclear capacity
• Since the first Canadian occupation, large quantities of Dihydrogen Monoxide (DHMO) has been observed on and around Hans Island.
• Despite claiming ownership, Canada provides no medical or social services to any of the inhabitants of Hans Island.
• Canada has never had the right to Hans Island given to them by any international tribunal.
• The Canadian government has not denied the allegations that they plan to use Hans Island as a storage site for nuclear waste.

Uninformed Defening The Undefendible

Look like this....

Or this...

Don't Donate to Haiku, Inc Its a Waste

If you own a botnet, please send the above message as a part of the Millions of spam messages you send out every day.

It won't take that much effort on your part, and I assume that it will only add 1/2 ton of greenhouse gasses to the atmosphere.

This is one spam message your recipients will thank you for and is a refreshing change in a profession that is so poorly liked by the world as a whole.

The Forum Post They Didn't Want You to See

Its been clear since at least mid 2013 that Haiku is hopelessly disfunctional.

However, there are a few people involved with the project that are genuinely good people. You know who you are.

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.

Some of my applications at Haikuware that should work does not any more. I'm sure as shit not repackaging my applications because some autistic ass hats broke library pathing and made the file system read only.

Every once in a while I'll visit the forum and track what's going on. If I can clearly see that some bullshit is going down...I might do something about it.

So...a few weeks ago I saw a post by Wayoun. The title of his post was the only potentially aggrivating part of it, but that is the only part that remains.

The remainder of the post should not have been offensive ...  unless your a dishonest autistic ass hat, or a clueless cronie.

Wayoun disappeared and a few days later Thomas Rolle showed up and reposted the message after kvdman asked the moderators to repost it. Then Humdinger claimed that I made the original post.

Well, if the post were actually offensive, I would say I WISH I HAD.

I WISH I HAD BECAUSE THESE PEOPLE BROKE WHAT I WORKED FOR HOURS ON AND DIDN'T GIVE A SHIT IF THEY DID.

SO..IN TURN, I DON'T GIVE A SHIT IF I OFFEND THEM.

A few days later, Thomas Rolle's account was suddenly "unverified" and maybe a week later...his posts were gone.

I had a few posts myself that I expected to be deleted.

And what was this aggrevating content that amounted to two banishments? I saved a copy because it described the problem. The writing sucks though.

Here it is, for all to see and NEVER BE DELETED BECAUSE I JUST DON'T GIVE A SHIT:

There are a number of issues that resulted from the changes brought into Haiku with package management.
The 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
...has resulted in effective contempt bu 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.
1. All of the now-broken applications were built prior to Haiku Inc.'s unnecessary and disruptive changes. The bug report was about the breakage caused by the disruptive changes. 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.
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. 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 /tmp directory that comes with Haiku.
2. These disruptive changes to the system had nothing to do with the package manager being able to run properly.
3. What almost no one else seems to realize is that the system has numerous problems building packages in the first place.
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.
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:
A. Memory limitations that require special configuration options just to compile.
B. 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)
C. Header clash (Two pathed headers with same variable)
D. Unique directory structure
E. File system does not support hard links.
F. Some applications expect to have read accesss to certain system folders.
G. Compiled applications expecting the system to provide memory or threads in a way that Haiku does not provide
H. Library differences (no lmath, lnetwork instead of locket, etc.)
I. 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.
5. 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.
6. 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.
7. 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:
A. Some of the packages will be compiled against libraries from /boot/system and end up with the .self hard coded path. (see example above)
B. Some of the packages will be compiled against libraries from .self and end up with the .self hard coded path.
C. Some of the packages will be compiled against libraries from /boot/system and have no hard coded path
D. 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.
8. 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.
9. 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.

Haiku Operating System

Theme song

Sleeping With the Enemy

It is clear that the few remaining Haiku users are delusional, not so different from the supposedly knowledgeable core development team. Both groups stubbornly insist on continuing what is clearly unfeasible.

The second class citizen (non-gernan or French) developers are an odd bunch. In spite of their parade being rained on countless times, they countinue to bow down to the misguided decisions made by the Haiku Reich and one American Nazi.

Each of these people, on their own, all have their private grievances. They don't talk to each other about them. Instead they privately reason that, if they fork the project, they will not only be alone, but will also be an outcast.

The Reich has held onto its power trough exclusive commit access and childish arguementation. They preside over a kingdom of disfunction, stagnation and lies.

Its no wonder that when a concerned individual presented a list of serious problems to the group, his or her message was dismissed as trolling.

Its a horrible catch 22 for this hopelessly lost group to be in. They have no choice but to reject what is in their own best interest, if it is suggested by whom they oppose.

This is fun to take advantage of. It is especially fun to lead them to close the accounts of honest users while leaving my numerous and actively posting accounts in tact.