Josh McDonald <j...@joshmcdonald.info> writes:
> Why should links be in the filesystem, rather than an application /
> UI construct?
For a lot of reasons. But the question is justified.
- because it would be more modular and represent more code reuse, to
factorize out the management of links in the file system module,
rather than having it in each application.
- because that would provide the user with a more consistent user
experience (both look and feel), than when each application implements
its own semantics and user interface to manage files (as we can see on
the horrible iOS and Android systems).
- because providing a generic tool to manipulate files let the users
control their data, contrarily to putting the application (and
therefore, unless it's a GPL application readable, understandable,
modifiable and compilable by the user, is actually a proxy of the
commercial or political interests that provide this application to the
slave^W user. Notice the qualificatifs, the GPL is not enough: how
many users can read, understand, modify and compile the source of the
GPL application they use (take for example LibreOffice oremacs). The
points here are that:
1- applications are not written in languages that are readable by the
(non programmer) users.
2- applications are not written in a way that is understandable by
their users.
3- and therefore, applications are not modifiable and compilable by
users.
Therefore, embedding important features such as file system management
into applications is strongly restrictive of users' freedom, taking
control over users' data.
The GPL idea would be that users could contract programmers to help
them with those point. How many times did users contract you to read
GPL programs, or to modify them? (cf. the recent openssl and bash bugs).
Until there is a lot of changes in the way applications are written,
and in the way they are licensed and distributed, embedding file
system management features in the applications (or in the frameworks
used by the application, like Cocoa and iOS try to do), is very bad.
> Why should there be 1 filesystem, rather than 0, or
> thousands?
Indeed. There can as many file systems as you wish, and a system should
provide a way to manage as many file systems as you wish.
The unix systems let you do that, with the mount(2)/umount(2) and
chroot(2) primitives. Linux helps even more with bind move and shared
mounts.
But otherwise, this question refers to capability based systems which
often provide explicitely set-up per-process directories to give access
explicitely to authorised files. Indeed, this seems to be a good way to
avoid a lot of security problems. The question is how to design a user
interface letting us do that conveniently enough. (And again, there's
the question of trusting the programs that perform those tasks anyways,
can those programs be read and modified by the users (with the required
"capabilities")?
> Why must a filesystem be a DAG + links, rather than some
> other graph, or a soup with a lot of queries?
See my previous answer. Again, you're right to ask the question. Trees
are but a simple way to manage files where the human user keeps control
of it.
Granted, when managing libraries of millions of pictures or mp3 songs,
other organization scheme, more automatic, and more multidimensional may
be required.
This becomes more a database than a (classic) file system. Should the
system integrate database systems to manage files (like old mainframe
systems), or should unix stay a uni-user simple system (unix) instead of
becoming a multi-user complex system (multics)? Just joking anyways,
I'm on the Lisp Machine side of things.
My point here is that it is a difficult problem to solve satisfatorily:
- you need to provide a generic file system module that is independent
of applications to let the user keep ownership of their files despite
using privative applications,
- you now need to provide a database system that works for all kind of
different applications with different requirements,
- nowadays, you might also need to integrate remote files (cloud
storage, etc), behind this database API.
> Why should a "link" simply be a file pretending to be in two
> directories at once, rather than a data-carrying relationship between
> two nodes in the graph?
Well, in the current situation, links carry information: their name, and
a few file system attributes are link-specific. An application can take
advantage of it. An example, is scripts with care called with different
symbolic link names and perform different actions accordingly.
But granted, in a database view of the thing, you might want to add
other attributes.
> I think these are much more interesting questions :)
Yes.
--
__Pascal Bourguignon__ http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
