GotoLinux reorganizes the standard Linux File Hierarchy System (FHS) to bring the layout into modernity. It achieves this by focusing on three primary goals:

User Centricity - We intend to reorganize the file system to give users priority over their machines. The original FHS was designed by and for operating system engineers at time prior to consumer computing. Even as computers have become house hold devices, the file systems has remained predominantly a black box, like the engine of a car that the owner never sees. But the file system should be a tool that the average user can take advantage. It should do more than serve as a "home" directory for saving and loading (or often loosing) application files.

Contemporary Design - The file system should be organized using modern structures and semantics instead of relying on terse relics of a bygone era. For example, it is no longer necessary to have separate bin and /usr/bin directories when systems can easily be repaired by booting a rescue image. Nor should these locations be called "bin" any longer since they can hold any type of executable file, not just compiled binaries, a dated term in itself.

Maximum Idempotence - Idempotent designs are those that prevent conflicts. So it is for Goto's software management. Software packages are divided between vendor directories, thus giving vendors a first-class footing in the system. Software packages are further divided by package name and version, so multiple versions of the same application can be installed and used. Going even further, different configurations of the same package version can also be installed if necessary.

The design of Goto's file hierarchy derives heavily from GoboLinux. GoboLinux is perhaps the first Linux distribution to really challenge the status-quo. From GoboLinux, Goto adopts the practice of clearly named directories and an extremely well organized tree, as well as it's approach to package management via the file system. In addition the GoboLinux Rootless system inspired the design of per-user layout.

GotoLinux also draws inspiration from objectroot. Objectroot gave us the idea of giving vendors a first-class footing in the structure of the package tree. It's idea of multiple hosts has also served as inspiration, combined with ideas from SmartOS we gain the design of a master/slave boot system. Objectroot also helped inspire user-centricity with it's idempotent layout between users, hosts and software organizations.

From NixOS Goto borrows configuration-based packages which allows software installs to reside in repositories independent of the hosts they are utilized by without compatibility issues.

The root directory of Goto file hierarchy is quite different from the FHS and all other file system layouts. Rather then starting with divisions of the operating system, Goto starts with the first division that really matters: users and by extension user groups. If are system has but two users, lets name them Tom and Mary, then our top-level directory, in its simplest form would look like this:

All/
Mary/
Tom/
Unit/

In this directory we have two user directories, Tom and Mary, and one user group directory, All, which is the omnipresent group shared by all users. The directory Unit is not a user or a group, but a singular entry the holds content relevant to the physical computer itself and it's fixed configuration, which includes the core Kickstart OS, bootloader scripts and partition mount points.

User directories have a standard layout separating personal files from application specific data, available hosts and software.

/Tom/
  Account/
    Apps/
      .Index/
    Cache/
    Data/
    Hosts/  (Optional ?)
    Setup/
  Groups/
  Homepage/
  Library/
  Network/

Notice that a user can have personal installations of software. Those of you familiar with GoboLinux might recognize this as Rootless, which is what inspired this design. Of course software and hosts are more typically shared via a user-group, like All.

Groups are essentially the same as users, but rather then hold the resources of a single user, their content is shared between multiple users.

/All/
  Account/
    Apps/
      .Index/
    Cache/
    Data/
    Hosts/
    Setup/
  Groups/
  Homepage/
  Library/
  Network/
  Public/

It might seem odd that the organization of software in the system allows it to be installed in any number of places within the hierarchy --a user, group or even a host. Each can have their own installs of software. Naturally one would think that this could lead to a great deal of redundancy and wasted disk usage. Indeed, imagine if a system had 100 users and each had their own install of Firefox. That would certainly be very wasteful! However, this is where Goto's philosophy of letting the computer do the work comes in. It should not be necessary for us to organize the file hierarchy in a non-user centric way just to accommodate a computers inability to optimize hard disk space with regards to redundant data. Instead we need to teach the computer to address this at a lower level. While it is only common sense for an administrator to install Firefox once in a shared group, it should not be a prerequisite for the resources of a system to be well utilized.

The Groups directory simply hold symlinks to user groups. Evey Groups directory has at least one entry pointing to /all.

Groups/
  All -> /All

It's the Internet Age, so why doesn't everyone have a personal homepage? While optional, by placing files in this directory, starting with traditional index.html the system web server will automatically serve it up under the users account name.

The library directory in an index of the Account/Apps software directory. It simply makes it possible to find resources within installed software by category rather then by vendor and application name. For example, under Library/Fonts one would find links back to locations in Apps/, thus creating a compilation of all available fonts. Likewise for other types of files. In addition a users personal files can be index in Library as well, making one's own files easier to find.

The Network directory contains links to other computers in a users network.

The Apps directory holds software installations, there are organized into vendor subdirectories, then application name and finally application version.

Account/
  Apps/
    mozilla.org/
      FireFox/
        23.0.1/

The Index directory indexes the contents of Apps directory using symlinks. It is akin to the Library directory but rather then index files according to type, they are index according to standard install locations of the original FHS. This is how GotoLinux is able to remain compatible with legacy system. If you are familiar with GoboLinux, the Index directory is the same as Gobo's Links directory.

Data is for long term storage by applications to save information. For example a game might want to save a high scores. It is organized by application name. Its function is equivalent to XDG's DATA directory and serves much the same purpose as the traditional var/ directory.

Setup used to store application configuration files. ts function is equivalent to traditional home dot-files and XDG's $XDG_CONFIG_HOME (~/.config) directory.

IMPORTANT: Hosts are very much an experimental concept at this point and will not be a part of the initial system.

Hosts embody operating environments. There can come in a variety of forms including Docker files, Vagrant files, VMware images, mountable ISOs or simple directory. When the Kickstart OS first boots it handles authentication of the user and allows the user to select from the the bootable hosts available to them --either in their own user directory or in a group to which they belong.

  Hosts/
    goto-science/
      Serve/
      Apps/
    debian7/
      bin/
      ...
    tincore-4.7.iso

In the example we see the user has setup a light-weight environment for doing scientific work. He or she also has a full installation of Debian Wheezy. This is called a foreign host since it is not a standard Goto host. What lies under this directory is everything a typical Debian install would have, from bin to var. Lastly we see an ISO image of TinyCore linux, another foreign host, but this time given in a bundled iso format.

Hosts can be utilized in one of four modes.

1. The recommended and most common approach is via a light-weight Linux container. This means running the system on top of the current GotoLinux ...

2. Foreign hosts have to use a virtual machine. The virtualization can be handled by VMware, VirtualBox, KVM, Xen, Qemu, etc.

3. If the host is Linux-based, as is the Kickstarter OS, then it can be hosted in a chroot environment. This is the most simplistic type of hosting and offers only basic safe-guards in limiting the users access to the rest of the system.

4. Lastly, the host can be retro-booted to take over the system. This is handled via a soft-reboot pre-configured to reboot into the host system. This approach has very little in the way of safe-guards since it allows the host to fully takeover the machine, but it also removes any intermediary system from slowing or interfering in its operation, which may be necessary in some rare cases.

One objection that might immediately arise from the user-centric layout is the inability to partition user files from system files. But this objection actually belays one of the points of this new layout --in modern systems those lines are blurring. Nonetheless, it is still possible to partition the layout as needed. The trick to mount the root (i.e. /) to the partition that would traditionally mount home. Then mount all to the partition that would traditionally mount usr. And mount unit, which really should be on a separate partition anyway, as we would boot. As for mounting tmp locations to a RAM disk, in that case mount the all groups temporary path to the RAM disk and then symlink everyone else's temporary location to it.

Capitalized directory names is becoming more common place.... Goto is no exception. But Goto will offer some flexibility (b/c if you are like me you prefer all one case). Our approach is to have file browsers (including the ls command) to respect stylization settings which would automatically style entries when viewing them. This approach should suffice, and in some cases work even better then depending on developers to always "do the right thing". Ultimately Goto should be able to treat the file system as if it were altogether case insensitive, even though actual letter case are preserved under the hood.

Software is stored is vendor repositories and compiled, if necessary, against host configurations rather then for specific hosts. This allows hosts with the same configurations to share the same software.

The hierarchy borrows a great deal from GoboLinux. But it might not be apparent how this is so just by looking at it because directory names have changed and a bit of reorganization has taken place. So this chart should help explain the correlation.

Programs         -> Account/Apps
Files            -> Account/Data
System/Links     -> Account/Apps/.Index
System/Settings  -> Account/Setup
System/Variable  -> Account/Data

A few notes about this transformation. First it is clear that the primary transformation is to move from a system-oriented design to user-oriented design. Second the Files directory was renamed to Data, but this change was already planned for GoboLinux 015, it was just never released. So this isn't really a difference, and we agree that Data is the better term. Renaming Programs to Apps is not something that would have been done just a few years ago, but the winds of change prevail over everything and the common term today is App, short for Application. You can thank Apple for popularizing this change in terminology. To go along with that shorter name, we renamed Settings to Setup. This is the one change that we wouldn't fault anyone for arguing with us over, it has only been change so the name is approximately the length of the rest of the directories. Silly, but aesthetic. Finally, Links was move into Apps and renamed to .Index. The name change was again something that was planned for GoboLinux 015, although it was intended to be used a with a special "ViewFS" system. We go along with the name change, but at least for now stick with the Links utility. It has been moved to Apps becuase all it's links come from there. By moving it into Apps the links can be relative.