Kaitlyn~EthyliaMay 21, 2023

I doubt many people will see this, but boosting is very much appreciated as I want to hear as many opinions as possible.

If you created your own file structure. would you have information relating to programs be separated by category and then app i.e.

State
App 1
App 2
Data
App 1
App 2
Sources
App 1
App 2
Binaries
App 1
App 2

(think like XDG base directories)

or separated by application, and then by category, i.e.

App 1
State
Data
Sources
Binaries
App 2
State
Data
Sources
Binaries

Category > App
50%
App > Category
50%
Other (say below)
0%
Poll ended at .
Show threadGabriela Noriega 🏳️‍⚧️ 🇧🇷

@kaitlynethylia Like #XDG definately! Their system is far better for backups and for storing stuff in different drives (e.g. the binaries on the SSD and the data on the HDD)

Additionally, doing things by category first helps with writing #AppArmour and #SELinux profiles.

May 21, 2023 at 3:42pmWeb
Show threadKaitlyn~EthyliaMay 21, 2023
@gabri interesting, I hadn't really thought about the security aspect of it. I would've said the other way around because usually I find when Im doing something in my file system, I need a lot of files to do with one all, not a lot of files of a particular category, making it easier to navigate
Show threadGabriela Noriega 🏳️‍⚧️ 🇧🇷May 21, 2023

@kaitlynethylia Yeah, but when we are doing security controls it's often very handy to say stuff like: only the console and the package manage can write to the /bin directory. It does however prevent apps from self updating but this can be solved by having something like /bin1 which is managed only by the package manager and /bin2 which is managed only by the apps themselves. This way we can allow self updates while keeping the system organised and secure.

As for the user side of things, I think that most people generally only really need to interact with their "data" files.

Show threadGabriela Noriega 🏳️‍⚧️ 🇧🇷May 21, 2023

@kaitlynethylia So, for an ideal OS I would go like with the following subdivision for each workspace (a workspace is like a subuser that can be shared):

/appname — data files

/.cache/appname — cache that can be cleared by the OS at any time

/.config/appname — config files that should be backed up

/.secrets/appname — stuff like authentication tokens and private keys, this is all auto encrypted with the users password

/.bin1/appname — files writable only by the package manager but readable by the application

/.bin2/appname — files readable and writable by the application

By default apps would only be allowed to access their own data folders but they can be granted permission to:

- Read (or read and write on) all non hidden directories in the workspace

- Read (or read and write on) specific directories in the workspace

Show threadGabriela Noriega 🏳️‍⚧️ 🇧🇷May 21, 2023

@kaitlynethylia

Notes:

1) Each folder under the user directory would be its own workspace by default.

2) Apps resort to user level config and secrets when the local workspace doesn't have the requested "key/file". (so kinda like how the Windows registry does it)

3) By default those "appname" parts would be like "com.adobe.reader"

4) My OS would distinguish file titles from file name. Basically filenames have to adhere to some annoying standards like no spaces and no special characters but the filetitles can be just about anything and can even include text formatting. This way the user can retitle those "com.example.app" dirs without renaming them and thus allowing for better flexibility without sacrificing interoperability. (yes, files and folders would have a special flag indicating if their filenames should be automatically changed when the file title changes)