3 ms·

I see what you are saying but I think it misses the point. We need a filesystem right now because data disappears from RAM when electricity goes away. With per

I see what you are saying but I think it misses the point. We need a filesystem right now because data disappears from RAM when electricity goes away. With persistent memory you don't need that extra serialization/deserialization step to/from the filesystem. Look, think it like this: 1. In memory we store our program code and data as blobs in various parts, in the stack, in a heap, some only for the current program, other stuff like shared libraries linked at runtime to various programs. It's a rats nest of pointers. 2. When we "save" or "restore" we takes that rats nest and pull out some of the important parts (e.g. we ignore the shared libraries in memory and the app code) and we serialize that state out to disk. 3. Then the file system takes that logically contiguous "file" and breaks it up into pieces and stores those across the disk in various blocks and writes metadata which describe how to put the pieces back together again. With persistent memory we can ignore steps 2 and 3 most of the time, but they still might be useful for sending data to other computers, especially step 2. Disclaimer: I read the slides but didn't watch the talk

pmontra 6y ago
Sending data to other programs in the same computer too. Example: 1. Download pictures from camera. You need a program to transfer them somewhere you can find them. 2. Choose 12 of them to make a calendar for next year (OK, let's assume we're already in November). You need a program to view them. 3. Edit them with your favorite. Save as copies, not to overwrite the originals. 4. Upload them to a web service using a browser. A file system is useful to support all of these steps. Android's share to other apps kind of hides the file system but it doesn't succeed 100%. Sometimes no app registered to handle some file type and we end up picking the file in a file explorer interface. Sometimes we even have to know where that app stores its files. My most usual case for this are the gpx files of OsmAnd, when I transfer them from the small phone I use as tracker to my main phone.
- 0xCMP 6y ago
  I'm very interested in getting rid of "Files" and making programs use/manipulate databases more, but the issue of sharing things has always been a problem. Like you say in Android, but also iOS, it's annoying. However, you've given me the idea of what if instead of registering to handle a file type and giving the user a way to select a file we made sharing better by making applications provide a kind of "Files" view in to their data which may simply be items in their databases. On iOS the app ShellFish provides a seamless view to the files on my servers inside of the Files app and the Files picker of the OS. In macOS the finder's file picker has a section for Photos which lets you select a photo without needing to export it to a specific file. We could instead select from applications on our system instead of going to each application and sharing each piece of data we need.
  - pmontra 6y ago
    When getting rid of files remember that there will be legacy OSes and media forever. In my example, that camera is storing pictures on a removable media, maybe FAT32 even in 2050. And there are good reasons for that: I saw mode than one person filling more than one 64 GB SD card with pictures on a 3 weeks journey. And at the end of the example the machine that prints the calendar might want individual files and reset its state at the end of each print. It can even be a way to resist to attacks that upload malicious pictures.

pmontra 6y ago

Sending data to other programs in the same computer too. Example: 1. Download pictures from camera. You need a program to transfer them somewhere you can find them. 2. Choose 12 of them to make a calendar for next year (OK, let's assume we're already in November). You need a program to view them. 3. Edit them with your favorite. Save as copies, not to overwrite the originals. 4. Upload them to a web service using a browser. A file system is useful to support all of these steps. Android's share to other apps kind of hides the file system but it doesn't succeed 100%. Sometimes no app registered to handle some file type and we end up picking the file in a file explorer interface. Sometimes we even have to know where that app stores its files. My most usual case for this are the gpx files of OsmAnd, when I transfer them from the small phone I use as tracker to my main phone.

0xCMP 6y ago
I'm very interested in getting rid of "Files" and making programs use/manipulate databases more, but the issue of sharing things has always been a problem. Like you say in Android, but also iOS, it's annoying. However, you've given me the idea of what if instead of registering to handle a file type and giving the user a way to select a file we made sharing better by making applications provide a kind of "Files" view in to their data which may simply be items in their databases. On iOS the app ShellFish provides a seamless view to the files on my servers inside of the Files app and the Files picker of the OS. In macOS the finder's file picker has a section for Photos which lets you select a photo without needing to export it to a specific file. We could instead select from applications on our system instead of going to each application and sharing each piece of data we need.
- pmontra 6y ago
  When getting rid of files remember that there will be legacy OSes and media forever. In my example, that camera is storing pictures on a removable media, maybe FAT32 even in 2050. And there are good reasons for that: I saw mode than one person filling more than one 64 GB SD card with pictures on a 3 weeks journey. And at the end of the example the machine that prints the calendar might want individual files and reset its state at the end of each print. It can even be a way to resist to attacks that upload malicious pictures.