Latest Articles

Why Haiku Vector Icons are So Small

How is it that the Haiku vector icons are so small? You might expect great hackery, but actually HVIF is pretty simple. When I tell you all the "secrets", you might just go "doh!". The most important thing is that the format is optimized for icons. Once you take this simple assumption and think it through, you find all sorts of ways to reduce the storage space.

Read More

Driver Development Presentation at WalterCon 2006

This is a transcription of the Driver Development Presentation given by Axel Dörfler at WalterCon 2006.

Contents

  1. The Device File System, devfs
  2. Modules
  3. Device Types
  4. Interrupts
  5. Haiku Specials

Read More

Sorting Chute

Body: 

The means of having the operating system automatically sort, file and perform actions on filesystem objects based on user-configurable criteria should be provided through the use of a "drop target" replicant known as the "Sorting Chute".

Details

The sorting chute would be comprised of three main components:

  • Replicant
  • Preference Applet
  • Drop Folder

Replicant

The replicant would act as a space on the desktop, designated by an appropriate visual representation, whereby filesystem objects can be dropped to have actions invoked upon them based on a set of user-defined rules.

Read More

Download Server

Body: 

Haiku could include a dedicated API and an additional server who's task would be to manage and optimise simultaneous downloads on a global level.

Details

In order to optimise downloads from a Haiku system it is proposed that all mass downloads be conducted using a dedicated download kit. Any software which wanted to download large files should use the download kit API to queue the download, query it's progress and other management tasks. Classes such as 'BFTP' would be required.

Read More

Realtime Audio Normalisation

Body: 

Haiku could benefit from implementing an automatic real time audio normalization system (i.e. An automatic volume adjustment system) at the mixer level on a per channel basis. It could utilise adjustable normalization schemes based upon given scenarios or channel purposes.

Details

Real time audio normalization could be implemented at the system mixer level in Haiku. This system would be designed to boost or soften sounds produced throughout the system to suit listener tastes or given conditions. E.g. Large quantities of digital media have extremely low sound levels throughout. But it is also impractical to continually adjust the volume of the player application. With this system in place, the digital media's volume could be scaled to an acceptable volume, while not affecting other audio playback applications in the system or requiring user intervention when switching to digital media with appropriate audio levels.

Read More

Shared Devices

Body: 

If Haiku were to expand and generalise on the popular concept of file and printer sharing there exists the potential for sharing of arbitrary devices, both physical and virtual, over any network. Devices would appear no different from a user's view when compared with local devices.

Details

Provider

On connection of a shareable device the user's computer would first ensure the device is allowed to be shared and if so, who is allowed to access it. The device would be kept in a list of shared devices which are externally queryable.

Read More

Layered File System

Body: 

The ability to mount filesystem's directory structure 'over the top of' existing mounted filesystems would allow for a number of simplifications for Haiku users' systems.

Details

Traditionally mounting a filesystem on a specific directory results in the new filesystem 'overriding' the specified directory, effectively hiding the original directory's contents. This restriction could however be lifted, allowing for layered, or union, mounting of systems.

When mounting filesystems the system will keep an ordered list of mount points. When file/directory/etc access occurs the system will traverse the mount list attempting to find a matching filesystem object in each in turn. The first match found is the one on which the system will act. Therefore, if there are two (or more) matches for a specific object the system first on the mount list will be used.

Read More

File User Polymorphism

Body: 

File systems could benefit by adding functionality which would allow files to behave differently based upon which user is currently reading them. Objects could have different contents, permissions and attributes.

Details

A file/user polymorphic file system would give file system objects the ability to behave differently, or effectively be different, for each user. It would allow all file information to be selected dynamically based upon entirely upon the current user. In more general terms, a file which is polymorphic could appear completely different, in terms of data content and meta-data, when viewed by different users. The only detail necessarily the same would be the file path.

Read More

DevFS Attributes

Body: 

Storing information about devices as attributes in the relevant areas of the devfs could allow much simpler (and more powerful) access to device specific data.

Details

There are many items of information regarding physical and virtual devices that require specialised APIs for querying. In order to implement this system an additional set of driver hooks could be added to retrieve the data. It has been suggested that using this method, driver complexity and extensibility (regarding PCI IDs) could be improved.

Read More

Cross Referenced Files

Body: 

This proposal suggests an attribute based system to label files as referencing other files in order to allow queries to utilise inter-file relationships.

Details

Currently files whose contents reference other files on the local system can only be found through interrogating the file's data or through other similar mechanisms requiring some insight into the file data. It is proposed that a system wide set of attributes be used in order to build relationships.

Read More