kernel

First of all, apologize me for my English, I know it not quite good but Im improving. I have posted before but they have been deleted (I dont know why).

Quality / Stability, Kernel

I wish that Haiku before have been or sooner if possible BeOS clone. Have some security and quality features, i propose that this OS have a memory execution protection, just to make the life easier and secure, just to enforce to make best programming practices. The thing is like this:

*proteccion to dont allow execution of code if its in a "not code" memory section/page. So to prevent STACK and HEAP/DATA execution. So the application could fail, but OS remain stable.

*proteccion agaist stack underflow and data/buffer/heap overflow. So bad programmed applications could not damage the Operating system in that way and compromise it.

*independant memory position aplication execution.

with all this open techonlogies (even could be implemented by software) not only could make the user life easier but the developer life too, becouse it could be much more easier too detect some common bugs without crash our system. I guess some BeOS application are not too good programmed so they used that bad techniques, so at first place we could use a COMPATIBILITY user allowed method (or even a listed application allowment for compatibility mode with old and bad BeOS bad programmed apps).

at last
*portable devices compatibility and support, like those that could be plugued inot usb port, ex: Mp3 players, video players, memory cards/sticks, IRDa, WiFi, Routers/Hub/..., external storage.

Network Interface

I wish a well firewall, powerful but yet easy to configure, with an advanced mode for experimented users. Preconfigurated with the common and best settings to do every day work.

*Here we could add, a good network interoperability with all Unix open standards royalty free (SCO, BSD, Linux), to make a good neighborhood this OS in a network.

User Inteface, Game Kit

In this part I really wish a powerful GUI with a simple interface, capable to do good 2D/3D work. With advanced features to made easy programming great games using that GUI-API. I must be easy to extend, but the User Interface must keep standard, with the option if you wish to make it customizable with something like skins disigned by users, but with out let it modify the kernel/drivers of the OS. I made enphasis on standard because it hard work to bring support when the GUI its so different, and even the final user (common user) dont even know it at all its features and diferent options positions.

What its important too bring success to this OS its make powerful and yet simple, but with some easy advanced features for that know how to use it. To bring applications for: word proccesing, calc sheet, slide presentation, a good photo processing ex.linux:GIMP, a good vector drwaing ex.linux:InkScape, good Developing tools, like IDEs, .NET power and simplicity; and not less important a good 2D/3D engine (integrated API) so they (open and close developers) could bring great games. With all this we could attract much more users and industry.

-Morthozz

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.

If the operation being attempted is that of file creation the system should create the file on the first read-write system found.

Usage

For Haiku users the system would keep a user specific set of directories with which it could overlay the system directories. Eg, A user may desire management of their own font directory. This directory could be mounted during login over the system font directory, thus removing the need for management of separate search paths.

The system would allow much freedom in areas traditionally protected due to permission constraints also. For example, installation of new software for a specific user is generally a difficult operation without resorting to increased privileges. However with layered file systems a user would have a (possibly blank) application directory mounted over the system application directory. Again doing away with multiple search paths and keeping the system much more cohesive.

Issues

• More specifics on handling of specific layers and filesystem operations?
• Does this system obfuscate the system internals where they are working adequately already?

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.

A short, and incomplete, list of file information that could possibly be managed via this process is,

• Contents, i.e. The actual file data
• Attributes
• Permissions

Foreseen difficulties mainly lie in the area of administration. It is difficult to determine how an administrator would be able to modify a given user's files if it was polymorphic. This could affect operations such as backups negatively. Also, depending on the specific implementation, it has been suggested that there could be difficulties in allowing multiple users access to the file system.

A possible implementation that has been suggested is to implement polymorphic symlinks whose target changes depending on the current user. This would fit nicely with existing file system methodologies and hence be one of the most transparent implementations.

Primarily the benefits of polymorphic file systems lie in the reduction of complexity from the user and application's perspective. They no longer need to take into account whether the system is multi-user or which user is logged in. There is a single file hierarchy for all cases which, without application or user intervention, changes to suit the scenario. However care must be taken to not hard code too many paths. Functions such as find_directory (located in the storage kit) should still be used to find specific directories for application usage as much as possible.

Direct uses are many and varied. The most popular of which is the ability to have the user's home directory managed via a polymorphic entry. This would also simplify the implementation of quick user switching similar to XP and Panther. Also, application settings files could be stored with the application itself, simplifying the copying of the entirety of a given application and its environment.

Resources

• Implementation of polymorphic symlinks with Linux and ext2

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.

It would be possible, if the required functionality were in place and attributes present, to utilise a kernel enforced naming convention for devfs publication. Eg, "this is a IDE raw disk node, on the 1st bus master device" could be used to create a kernel defined devfs path.

Applications

Many applications exist such as,

• Video card frame buffer address
• Manufacturer ID and device string
• Ethernet MAC address

In addition to these examples the use of queries would provide an extremely powerful user interface to the hardware information.

Extending the OpenBFS/BFS via the usage of calculated attributes for arbitrary files and file types would provide a useful means of dynamic and constantly up to date meta-data on many types of files.

Details

On top of the current methods to define and maintain file attributes under OpenBFS/BFS, there could exist methods to define calculated attributes for arbitrary files and file types. The calculation may be based on other attributes of the same file, globally defined values or value lists and other special information like item count for queries or folders.

Importantly, when a value which a calculated attribute uses changes there must be a method to recursively trace all dependent calculated attributes and re-calculate any affected formulae in order to keep all attributes up to date. In the case of attributes which have been indexed, the appropriate indices must also be updated at the same time.

Such calculated attributes may be defined on a per-file basis (in the form of a specially flagged attribute, which indicates it has to be evaluated as opposed to just its formula string used as value); or in the MIME DB for various file types.

In the latter case all files of the according type would "inherit" them. This would be possible because in order for a file to have a value for such a calculated field, the file does not have to specifically provide it, as opposed to normal attributes which have to provide a specific value. Calculations for which some source attribute are missing would take the concrete value of , or maybe an empty value (NULL).

An implementation of this system would need to be aware of problems relating to recursive calculated attributes and enforce restrictions such that all calculations are acyclic. Many modern DBMS with similar functionality have overcome this problem.

Potential uses for such a system are numerous. Backward compatible attribute names could become useful. E.g. An attribute called "Subject" which takes on the value from MAIL:subject or NEWS:subject or from the file name, depending on whichever one exists. Another obvious usage is in digital media, where many file types have independent mechanisms for meta-data storage. An abstracted method to gather information from MP3, OGG, WMA, etc would prove invaluable for media developers and users alike.

Fildirutes are an idea for file system naming and simplification. Rather than having separate APIs for files, directories and attributes (and indices too!), you have a single fildirute kind of thing. You can read data from it like a file. You can also open it like a directory and see what's inside. The things inside are fildirutes too. A small one inside would be like an attribute, the name would tell you what the intended purpose was.

Example

If you had a document called "MyDoc", then reading data from it would give you the document text. Looking inside it as if it were a directory, you'd see "MyDoc/mime-type", which if you opened it and read the data, would give you "text/plain". There could also be things like "MyDoc/Thumbnail" which would have "MyDoc/Thumbnail/mime-type" containing "image/png", and "MyDoc/Thumbnail/Width" containing 32 in binary, and for completeness, "MyDoc/Thumbnail/Width/mime-type" would contain "number/int32".

Eg,

MyDoc

MyDoc/mime-type

MyDoc/thumbnail

MyDoc/thumbnail/mime-type

MyDoc/thumbnail/width

MyDoc/thumbnail/width/mime-type

Of course, under the hood the small fildirutes are stored much like current attributes are. Some of them are also dynamically generated, and don't really exist, like the "mime-type" ones. It's just that the API is simplified so that everything is accessible as a fildirute. There is only one "open" function in the API, and just a plain "read" for data, and a "readdir" to find contained things. And "close". And that's it.

First, let me start out by stating that I use Unix (Solaris) almost every day. While I am not the master of all things Unix, I have a better than average knowledge of it, I like to think. I like a great many things about Unix. Pipes are probably the most useful concept I have ever seen in computer science. It is componentization of software some 20 years before it came into vogue.

While I like Unix, it has some issues, too. Some ideas whose time is past. Some concepts that are outdated and need to be replaced. I believe that foremost among these archaic constructs is /dev.

I can hear the wailing already. Hear me out. For those not initiated in the rites of the acolytes of Bell Labs, /dev is the directory where devices are mounted. So you could look at see /dev/tty for a teletype device. Or /dev/prt for a printer. Back in the days when everything was character based, this was exceptionally powerful. If you wanted to get input from a device, you could do it right from the command line. cat < /dev/foo. Very nice. Or send output to a device - cat tmp.txt > /dev/bar. This has served us well for a very long time, but that time is past.

The first issue that I take with this approach is that most devices are not simple minded printers or modems or teletypes anymore. It doesn't make any sense to say cat < /dev/scanner. Few people want to deal with joysticks, ethernet cards or video cards from the command line in this way. Much of the benefit of making your devices accessible easily from the shell is gone.

Secondly, / is a place for files. Overloading it with devices and other various hardware interfaces doesn't make sense to the average user. Why does it make sense to have a video card in /dev?

Thirdly, from a programmer's point of view, using *only* open, close, read, write and ioctl on devices no longer makes sense. It forces us to funnel every possible command that couldn't be forseen by guys with teletypes to go through ioctl. Think about the act of setting up a scanner for scanning. You end up with code that is very hard to read.

The ioctl commands must be published and (hopefully) standardized. Say you are writing a CD ripper. If one CD Rom's ioctl for "start rip on track 4" is different from a different driver's command, your code must account for that, if you want to work with both devices.

With /dev, you have to know the name of the device that you are interested in. Or, at least, what directory the device driver will publish itself to (yes, that is hard coded). So if you publish an app for, say, MIDI manipulation, you will probably search for /dev/serial1. But what if someone has a /dev/usb/midi/1 device? You can't work with it.

The /dev directory has been filled, too, with "psuedo" devices. The most obvious is /ptty - psuedo tty's for use with PCs. But there are others - kmem (kernel memory) is a good example. This is a nightmare for beginning users.

While I could go on, I have to leave room for the solution to this issue...

BeOS has a wonderful concept called rosters. A roster is basically an "intelligent" keeper of a list. You can use the roster's API questions and it can respond with items or sublists. My concept is a device roster. All devices would have a roster entry that allows you to get one or more device classes back. You can query based on type of data or on device type. For example, you could ask for all devices that can return anything in the mime type "image/". This should return digital cameras, scanners, hard disks, etc. Or you could query for every printer device, etc. All of these devices should derive from a common class (BDevice or some such), but be subclassed (maybe more than once). As an example - a CD ROM drive could be BDevice-->BMassStorage-->BCDRom. This would allow developers some flexability in addressing devices - they could choose to dig deep in the features or they could stay shallow and address more devices.

On a related note, I think that this would open the door to a different type of file panel. How about a BImageFilePanel? One that queries the device system for image yielding devices and has neat features like thumbnails, etc? Or a BSoundFilePanel that lets you play snippets before loading the whole file?

This system should also make it easier to deal with device configuration. A single application could exist that shows all of the devices. They could be configured via a single GUI, using standardized interfaces.

There are certainly details that would need to be worked out, but I believe that this system would be far more powerful and would shed the legacy pain of /dev.