Where's `/etc`? Where's `~/.local`? Where's `/proc`?? Straight answer? They're gone...
Maybe you've been using Linux for years, hell, maybe even decades. You know every Linux and Unix standard, and you expect things to live in a certain place. So why the absolute... would we move everything? It's not that we had to, it's that we wanted to, and the answer comes down to philosophy.
Imagine you've just rented your own space, your space to do whatever you want with. There's only one problem. You come home from work and find out the land lord told your neighbors they can put their extra stuff all over your place, and it quickly sets in that you don't really own the space you're paying for.
This is a matter of philosophy. Users should own their spaces, system files should be neatly segregated, and items like the user's home folder are not a dumping ground for any application that feels like it.
First, let's talk about how Linux as an "ecosystem" came to be what it is in the first place. Rather than coming from one unified design philosophy, Linux as it is today came into being through the work of many disconnected individuals and philosophies. Individuals we can justifiably call "atypical", whose minds operate differently than everyday users.
To those people, it's obvious that `/proc` holds running processes, `/dev` holds devices and `/var/log` holds logs. To everyone else, those names say nothing. On DivisionOS they're simply `/system/processes`, `/system/devices` and `/system/logs`. The name tells you what's inside.
::names
And worst of all, in the beginning the concept of "userland" wasn't something people really thought about. After all, Linux wasn't made for "users", it was made for and by the "atypical", and to those people, dumping a bunch of files in a user's home directory "feels right". On DivisionOS, your home folder is yours, and nothing lands in it unless you put it there.
In Linux there have always been arguments about what goes where and why it goes there, with many different teams and developers going back and forth in loose, loose scenarios, and almost no one being left "perfectly happy". Even today, with the FHS (the Filesystem Hierarchy Standard), things still aren't standard because of these disagreements, with several distributions deciding to use their own filesystem layouts and structures.
This is because Linux was never developed in tandem, nor in perfect agreement. It was built in pieces, often in near isolation, with competing ideas pulling against each other on message boards, telnet and IRC. Competing ideas most commonly won not on merit and design, but on user adoption. Sadly, it's not always "the best design wins", but more often than not "the first design that reaches adoption wins". This is where filesystem fragmentation comes in, and we can still see it today between Fedora, Debian, Arch and others.
From the very beginning, DivisionOS was built on the idea of plain text, readable systems and, most importantly, user intent. These ideas are the very core of every single system design we've chosen, from the filesystem to our own experimental plain English shell. Users don't want to `cd /myfiles`, they want to `goto /myfiles`, and the average user won't look for `/var/log`, they're looking for `/system/logs`. This is the basis for our filesystem changes.
Aside from the idea of trying to map and follow common user intent, we also wanted to change the way things are moved around and stored on the system: a system that lives in the same spirit of an easy to understand mental map.
A system where programs don't live randomly wherever a developer or maintainer decided to throw them, in `/bin`, `/sbin`, `/usr/bin`, `/usr/sbin`, `/usr/local/bin`, `/usr/libexec`, `/opt` or `~/.local/bin`, but where every program lives together in one place: `/programs`.
::programs
This same idea follows through with a structural rewrite of the entire filesystem layout. You can see this in our `/system` folder, with plain and easily noticeable items that don't require a computer science degree or multiple YouTube tutorials for everyday users. Folders like `/system/temporary`, `/system/devices` and `/system/config`, all of which are instantly understood by the very nature of their existence.
When it comes to free floating files such as program configurations, we've stripped their ability to land wherever they want and instead dedicated two individual locations. The first is in the program's own folder, `/programs/blender/config`, with each config folder carrying its own user protected folders. The second, is in the user's home directory: `/home/<username>/.common`. The reason we've moved everything to `.common` is because we needed a place that was, well, "common", and again easily readable and instantly identifiable. For example, SSH keys now live in `.common/keys/ssh`, and certificates live in `.common/certificates`.
::home
We could have saved ourselves months of work, feeling trapped in edge case hell, the obvious "why the... did you do that", and a metric ton of effort if we had just left things alone. And worse, we would be a lot further along in feature development if we had simply moved on without these changes. But I believe we would be a lot worse off for it.
DivisionOS is about solving user problems, and one of those problems is that users generally don't know what they're looking at in the filesystem. In DivisionOS they do. And better yet: for everything a home, and a home for everything, with no files orphaned, abandoned or left to make up their own minds.
So did we have to do all this? Or did we simply just want to? Or maybe a little bit of both?
Either way, it doesn't matter. It's done, it's built, and we feel users are better off for it.
