3 ms·
I think files have proven themselves to be a useful abstraction in enough use cases across enough device form-factors to be worth backporting into whatever your
by spaceheeder 10y ago
I think files have proven themselves to be a useful abstraction in enough use cases across enough device form-factors to be worth backporting into whatever your idea of an ideal lisp machine might be.
You could, with a non-trivial amount of effort, replicate the file-like conveniences of global tagging and sorting and organizing of all the objects in your image. You could, also with a non-trivial amount of effort, work out the schemes for permissions, etc. so that objects with all those file-like conveniences can be shared, like files, on multi-user systems or between machines or over networks.
It's not clear to me that the above would offer any tangible benefit over files. So if you're going to put a non-trivial amount of effort into a lisp machine, why not just teach it what a file is?
- DonaldFisk 10y ago> I think files have proven themselves You will need to store data which doesn't fit into RAM in secondary storage. But that doesn't mean you need a file system or even files. > to be a useful abstraction Files are a necessary evil in non-image based systems because you need to store data somewhere when the programs using them aren't running. As the different objects they contain, such as plain text, hypertext, photographs, sound recordings, executables, etc. have nothing in common, they seem an unnecessary abstraction. They require that programs which use them parse/serialize their contents. This is unnecessary if the contents are already in memory, already in the format the program needs. > replicate the file-like conveniences of global tagging and sorting and organizing of all the objects in your image Why remember a file name and where it is in the directory tree when you could use a search engine to search for it based on content? Or simply chain through objects, going to the field you want and following the link? Programs, of course, will just directly link to the object. > work out the schemes for permissions I'd go for capabilities, rather than access control. > why not just teach it what a file is? Building a file system is a major undertaking. If it can be avoided, and to the extent it can be avoided, it should be. You would only need to know about files when you interact with systems which are based around files.
- TeMPOraL 10y agoI think files are pretty cool because they're loosely coupled with programs. I.e. you can open and edit text or audio files in whatever you like, and even highly-specific binary formats like .doc or .psd have various levels of support in 3rd-party tools. This serves a very useful purpose of ensuring your data is truly yours, and will outlive the program in which it was created. This is a place where IMO we're taking a huge step backwards now, with increasing amount of work being done in the cloud and mobile ecosystems - both shed the concept of files for some amorphous database entries somewhere, thus taking away your control over your data. Can you preserve this flexibility/loose-coupling feature in image-based storage? I don't know. I'd be interested to learn if it can be done so.
- nickpsecurity 10y agoYou can do the same with objects. Difference is the semantics is more flexible with an implementation that can be as simple or complex as you want. INFOSEC research used this to advantage where things like PSOS built files on top of simpler store and things like DASD could build in analysis or encryption at disk/object level.