We take the security of our infrastructure and operating system seriously. Personal data is an important resource, and we want to ensure users can place their trust in Haiku.
Haiku Infrastructure Our infrastructure contains sensitive personal user data, and we aggressively keep this information private on a need-to-know basis at all times.
If you have discovered a vulnerability, CVE, or exploit that you believe puts user data at risk, please submit a detailed report to contact@haiku-inc.
What is a Haiku Hybrid? Haiku hybrid images are Haiku releases which can compile and execute programs built for incompatible ABIs. This may mean different architectures like x86-64 and x86, or different, incompatible compilers like gcc2.95 and gcc8.x for x86. Currently only the latter case is supported. gcc2.95 gives Haiku binary compatibility with native legacy applications written for the BeOS. In a Haiku Hybrid, there is the primary GCC or architecture and the secondary GCC or architecture.
With the introduction of package management, optional packages - and therefore this page - became obsolete. This page details the steps in creating an OptionalPackage. In addition to being a regular binary distribution archive, an OptionPackage includes a plain text file called .OptionalPackageDescription and possibly the license file. NOTE: With the recent incorporation of package management, OptionalPackages are obsolete. Haiku package files (HPKG) replace them. See PackageManagement/BuildingPackages and HaikuPorter / BuildRecipes for instructions on creating HPKG's.
As with many other FOSS mailing lists, we at Haiku hold ourselves to a few rules when posting to mailing lists. For now most of these are to ensure that all information is properly archived or to improve a message's readability. In the future this list may be expanded with additional detail. No Attachments Not only are attachments inconsiderate to low-bandwidth users, they fail to be preserved in the archives.
In addition to configure options, UserBuildConfig is another, very powerful opportunity for customizing your build. As of changeset [29161], Haiku's build system supports two locations for UserBuildConfig:
$(HAIKU_TOP)/build/jam/UserBuildConfig
$(HAIKU_TOP) refers to the top level of your local copy of the Git tree. If you use an external object directory, the UserBuildConfig at this location will apply to all of them. $(HAIKU_OUTPUT_DIR)/UserBuildConfig
Typically, $(HAIKU_OUTPUT_DIR) is $(HAIKU_TOP)/generated. However if you use an external object directory, then it UserBuildConfig is in that top-level directory.
Haiku uses a custom fork of Perforce's Jam. This mailing list thread helps to explain the decision to fork jam. As of August 2019, this is the current version. If a different version is reported, then you will need to build and install jam from source. jam -v Jam 2.5-haiku-20111222. OS=LINUX. Copyright 1993-2002 Christopher Seiwald.
Command Line Options Only some of the options are being discussed here. See jam -h for a full listing of available options.
Like many other software projects, Haiku allows a user to run configure from a directory outside of the source tree. This will cause the build system to use that current directory as the target location for storing the output from compiling, otherwise known as objects.
There are a few reasons for doing this. Multiple products, such as x86_gcc7, x86_gcc2, or arm can all be built from the same source tree, which reduces disk space usage.
Body: In reading some of the posts on R1 and R2 (especialy in regards to the quality of user experience) I realized that maybe more conceptual and inovative approach would to OS media design experience would also be attractive for first time users.
For example - just like using vector graphics (especialy in icons) that would make the interface scale and look better, it would be also interesting to use procedural/generative media.
This paper presents the implementation of system calls in haiku, and especially on x86 systems. The system call mechanism is what allows user land code to communicate with kernel land code. The whole paper is focused on the example of one system call: is_computer_on. This api tells if the computer is currently powered on or not. Using this system call as a study is interesting because its implementation is quite simple, and it is a historical one in BeOS system (with its brother is_computer_on_fire, but it is not a system call in haiku :).
Body: When one grabs an icon (file) with the LMB (left mouse button) and drags it to another location or surface, the file is moved or copied depending on it's location, after the user lets go of the mouse it can be seen that the file has been copied (the file is still in its orinal location and in the new location) or has been moved (the file has disapeared from its orinal location).
