First up is the structure of the filing system. I really wanted to clean up that mess
Code: Select all
app applications (same purpose as /opt)
com common files (same purpose as /home and /root)
<username>
dev devices
env environments (same purpose as /usr)
<envname> (same purpose as /usr/local and /boot)
lib libraries
man manuals
obj objects (same purpose as /bin and /sbin)
reg registry data (same purpose as /etc)
res resources (same purpose as /share)
var variable data
mac machine (same purpose as /proc)
net network
sys system files
vol volumes (same purpose as /mnt and /media)
The 'app' directory will contain applications. Each application is a subdirectory or *.a archive file. The benefits of this approach are that each application can contain metainformation and embedded resources regardless of the format of the object files. The self-contained archive files are similar to how Mac uses *.dmg files. One idea I had in mind is that you can execute a subdirectory like a program if it contains the metainformation for an application.
The 'env' directory will contain environments. It's like having multiple /usr/local directories on Unix systems. One example use for it is to create a separate environment for each user, but it's not limited to that alone. It may also be used to have both 32 and 64-bit environments, which may be used selectively depending on the application being executed. With the addition of environments, the need for a 'boot' directory is nullified (since a tmpfs can simply be another environment). The 'run' directory can be put back in 'var' where it belongs. Additionally, I'd prefer that 'var' be used instead of 'srv'. They literally have the same exact purpose, they only confuse people about where to put their stuff at and in some cases lead them to break things.
The 'mac' directory replaces the 'proc' directory. The name 'proc' is misleading imo because the directory contains a lot more information than just data about processes.
The 'net' directory was added as a mount-point for machines on the local network.
The 'vol' directory is a merge of the '/mnt', '/cdrom', '/floppy', '/media', etc. directories. Having this crap spread all over the filing system is annoying to me. The two reasons I chose not to stick with '/mnt' were the lack of defined structure and the fact that I'd like to get rid of sexual joke names like 'touch', 'mount', 'finger', 'fsck', etc.
The 'reg' directory will replace the 'etc' as a place specifically for registry data, and nothing else. This is essentially what the 'etc' directory has became over the years anyhow; and it's purpose is more apparent to people coming from a Windows background.
The 'com' directory will replace the 'home' and 'root' directories. Why? Because having homes inside my home is an inception I can do without and as far as I can tell, the 'root' directory is unneeded.
UPDATE #1:
I've been thinking about creating a 'streaming system' to manage how audio streams are processed. Like in windowing systems where you normally render windows across multiple or individual displays; the streaming system would let you render streams across multiple or individual channels. It'd basically work the same way. You'd have a Channel Server, Stream Manager, and Filter Toolkit. To get audio input or output, you'd first open a channel and create a stream to use. Then you'd just use the filter toolkit to create filters that manipulate samples of the stream. Like with widgets, while you can create custom filters, there would be a lot of preset filter types for things like echo and reverb.
[EDIT] Now I think about it, this setup would actually be a really good way of handling video input from cameras as well.
UPDATE #2
In addition to a 'public' directory, I think each user should have a 'mobile' directory that's syncronized across devices. Perhaps the underlying mechanism here would be that each user is automatically assigned a GUID, but it may be manually specified. When 2 or more devices have a home directory for a user with the same GUID, the timestamps for each file in the mobile directory on each device will be compared and most recently updated files will overwrite the older ones on each device.
UPDATE #3
Decided on a name. Originally, I was just using '?' as a placeholder. When I asked myself what wanted to call it, the Yoda-speak translator in my brain responded, "'What', I want to call it.". The name is thus 'Que', the Spanish word for 'what'. Just a funny coincidence, 'Que' (pronounced 'kay') is based on Unix systems which are often labelled as 'X'. A single letter connotation. 'K' looks and sounds like 'X', but it's not! Just for the added humor, I think I'll use '¿?' as the logo. One advantage to this is that it can be displayed in the terminal since both characters are part of the extended ASCII character set.
UPDATE #4
I've been thinking a lot about the object file format. While I do want to add PC support, my primary focus is embedded systems. Since you may have a small amount of RAM and lack a MMU; I want to enforce that all libraries are linked as PIC and all programs are relocatable.
