Le 7 avr. 05, à 14:33, David Chisnall a écrit :
On 7 Apr 2005, at 05:40, Jesse Ross wrote:
- Complete control. …
I agree. OS X gains a huge amount by being able to develop GUI
components for system level stuff neatly. Something like GNOME, for
example, can't easily contain a network configuration app, since
different operating systems (and even different distributions) do this
in slightly different ways. By having a complete OS we could easily
add this kind of thing, and not have to worry about cross-platform
support (of course, non-OS specific things would still work on other
platforms). Perhaps the OpenSSH approach would be a good one to
follow - OpenSSH has an OpenBSD branch and a portable branch, the
OpenBSD branch contains some additional features that only work on
OpenBSD (in our case on the Étoilé OS) while the portable branch
contains all of the parts of the implementation that are not platform
specific (the Étoilé DE).
For network configuration I don't think it would so much solve this
issue compared to Mac OS X or Windows, because recent GNOME versions
finally manages network configuration fairly well with
system-tools-backend (I would like to use it for Étoilé) which is
supporting many OS or distros. The problem lies more in exotic drivers
support (like modem, printer etc.) which is not so good with Linux and
sometimes bad with other OS, and we have no control over drivers :-/
Nicolas suggested a while back that he would be interested in building
a GNUstep-based system on top of DragonflyBSD to take advantage of
some of the low-level message passing mechanisms it provides for
distributed objects. This could also be interesting, although I
believe that Dragonfly is currently x86 only.
Yes, but ports are planned sometimes in future. :)
Ideally, I would like to see a system based on L4-HURD, since the
design is really slick, but unfortunately it doesn't really exist yet…
hehe.
We would also be able to add kernel / base system features that would
enable extra high-level features. I intend to extend the KEvent
system in NetBSD, for example, to allow an application to register to
receive notifications of /any/ changes to the filesystem, not just
those for a monitored file descriptor - the mechanism for this kind of
notification already exists in Free- and NetBSD (but not in Linux),
although this particular notification has not been implemented.
Well it seems it is going to be supported for Linux with inotify patch
and similarly it won't rely on file descriptors to avoid open file
descriptors limit, that would allow to observe complete directory
content (subdirectories included) or even a whole file system. Beagle
<http://www.gnome.org/projects/beagle/> project is precisely using
inotify to track file system changes and then trigger reindexing.
However kqueue allows to monitor any kernel events unlike inotify which
is just focused on inodes iirc, so they both intends to solve different
issues…
I would be very excited by such kevent extension, which I hope will be
not so hard to backport on other BSD variants.
- A buffer or visual pasteboard / quick launcher.…
I would like to see something like the shelf, but not attached to any
particular window, with exactly the functionality described by Jesse.
I also like Nicolas' idea of a shared shelf, possibly using XMPP's
publish-subscribe mechanism. (Nicolas: I intend to spend more time
working on my XMPP framework / client once my current paper deadline
has passed in a couple of weeks time. Honest. I may even finish the
GNUstep port…).
ok cool.
Possibly. This seems to be where Apple is going (apparently
implementing Spotlight is less effort than fixing the Finder…). I
rather like managing my own documents, and I can usually find them
quite easily. My main gripe with current systems is not that they are
hierarchical (the human mind is particularly well evolved to interact
with hierarchies, and they are a good model), it is the fact that
there is no separation between the model and the view of the
filesystem.
I agree.
To me, a folder is simply a file with some meta-data indicating that
other files are children of it. The parent-child relation should be
no different from other meta-data, and should be a many to many
relation (i.e. any file can have many children, and any file can have
many parents). This allows some nice things with file management
(e.g. a shared library can have a shared library folder and the app
which included it as parents, or a document can easily be in a saved
search result folder and in the place where the user stored it).
Current systems make it very different to have multiple, independent,
views on the filesystem.
True.
This idea is already implemented by ExtendedWorkspaceKit's persistent
objects (EXContext class currently) to allow such future possibilities.
A while ago, I proposed the idea that a clipboard should actually work
as a clipboard. The current clipping should be added to the top, and
when it is removed the previous clipping should be at the top of the
pile. The biggest advantage of this is that a copy operation would no
longer be destructive (i.e. you can return to your previous clipboard
contents by removing the top page from your clipboard). This would
require the addition of an inverse-cut operation (something that would
take the contents of the top page of the clipboard and remove it) - I
suggested that copying an empty selection could be used for this in
existing applications, although a more intuitive solution would be
better in the long-term.
That's an idea to investigate, but with PickDropKit copy/cut/paste
would just store the selection content in a snippets-oriented-shelf, I
think then we could add history-like relation between the snippets to
provide undo/redo (with stack model).
- Everything is undoable. Everything. Forgiveness is a virtue... and
a requirement for a friendly system.
Definitely. One thing that would be /really/ nice to do, which would
only be possible if we were implementing a full OS, rather than a DE,
would be to add buffering at the VFS layer, so if a device becomes
unavailable (e.g. a user pulls out a USB pen drive without unmounting
it), they are given a dialog box informing that they should plug it
back in. If they do, then the system should re-attach file open
descriptors to the files that they represent (while the device is
unplugged, i/o operations on those file descriptors should block. If
the user selects dismisses the dialog box without re-inserting the
device then they should fail). If the user does reattach the device,
then the system should
That's precisely what DragonFlyBSD VFS should allow when finished (this
year probably).
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
