3 ms·

the problem as you said is that the common denominator between all filesystem that are currently in use is to practically forget that metadata exist because you

by gryn 2y ago

the problem as you said is that the common denominator between all filesystem that are currently in use is to practically forget that metadata exist because you're only one filesystem transfer away from it disappearing (copy from one hdd to another, sent to cloud, transfer with a usb, etc ...) the other problem is that the filesystem/ desktop environment closely entangles 2 concepts that imho should've been more orthogonal. - data storage+indexing for apps (a common unified KV store would've been more general abstraction that can be used to build upon other kind of abstractions, would be nice if yo could define your own indexing instead of what's done with folders) - data/information access for users in the "desktop environment"

rchard2scout 2y ago
>common unified KV store So, something like the Windows Registry?
- rakoo 2y ago
  The windows registry is more a unified configuration file for the whole system, I think what GP talked about is more about a general store for data
- hobs 2y ago
  Well, I was going to say "limited key size" but it looks like in current windows versions the size is "available memory" so... yeah.
TeMPOraL 2y ago
Isn't Android an example of disentangling those concepts? Apps have their own folders, isolated from each other, to store data in, but then they present a completely different view of that data to the user. The user is discouraged and often prevented from working with files and the filesytem, instead, they're made to work with opaque apps. I really, really hate this design.
- gryn 2y ago
  yes you're right. but that one instance of doing so, but not the only way. I dislike it too since they put an emphasis solely on the app and not on the data. what I had in my was just idle thoughts about providing disentangled primitives that could be used to build other things on. for example the primary key for accessing a file/object could be (computer_id?, storage_id or partition_id , object_id/inode) + ways to define different kind of indexes based on you use cases. instead of just making apps into silos you can have the things builts on top of these primitives be typed structured data objects + API/interface. have an Object explorer and programs can declare they they are able to display or manipulate custom data Type X. you can then have GUI be composable the same way the pipe operator work in the cli. you can define a regular filesystem on top of these primitives, a relational database, a tag system, or something new all together. if you don't want folders you would ca to deal with them. the work on fushia OS seem to explore something along these lines (BlobFs + MinFs + Components). (https://fuchsia.dev/fuchsia-src/concepts/components/v2/introduction https://fuchsia.dev/fuchsia-src/concepts/components/v2/intro...) Pharo/SmallTalk seem to also explore the ideas akin to this. (https://pharo.org/ https://pharo.org/) to be fair the current state of affairs is similar enough with file extensions + mime info if you squint hard enough and pretend that app and systems folders files don't exist but it's held with pinky promises.

by gryn 2y ago

rchard2scout 2y ago

>common unified KV store So, something like the Windows Registry?

rakoo 2y ago
The windows registry is more a unified configuration file for the whole system, I think what GP talked about is more about a general store for data
hobs 2y ago
Well, I was going to say "limited key size" but it looks like in current windows versions the size is "available memory" so... yeah.

TeMPOraL 2y ago

Isn't Android an example of disentangling those concepts? Apps have their own folders, isolated from each other, to store data in, but then they present a completely different view of that data to the user. The user is discouraged and often prevented from working with files and the filesytem, instead, they're made to work with opaque apps. I really, really hate this design.

gryn 2y ago
yes you're right. but that one instance of doing so, but not the only way. I dislike it too since they put an emphasis solely on the app and not on the data. what I had in my was just idle thoughts about providing disentangled primitives that could be used to build other things on. for example the primary key for accessing a file/object could be (computer_id?, storage_id or partition_id , object_id/inode) + ways to define different kind of indexes based on you use cases. instead of just making apps into silos you can have the things builts on top of these primitives be typed structured data objects + API/interface. have an Object explorer and programs can declare they they are able to display or manipulate custom data Type X. you can then have GUI be composable the same way the pipe operator work in the cli. you can define a regular filesystem on top of these primitives, a relational database, a tag system, or something new all together. if you don't want folders you would ca to deal with them. the work on fushia OS seem to explore something along these lines (BlobFs + MinFs + Components). (https://fuchsia.dev/fuchsia-src/concepts/components/v2/introduction https://fuchsia.dev/fuchsia-src/concepts/components/v2/intro...) Pharo/SmallTalk seem to also explore the ideas akin to this. (https://pharo.org/ https://pharo.org/) to be fair the current state of affairs is similar enough with file extensions + mime info if you squint hard enough and pretend that app and systems folders files don't exist but it's held with pinky promises.