On 7 Apr 2005, at 05:40, Jesse Ross wrote:
I asked Nicolas, Quentin and Banlu about their ideas on developing
Étoilé as a full operating system (on top of Linux or *BSD or Hurd
(one day... maybe...)). All three mentioned being in favor of doing a
desktop environment instead. I personally am interested in a full
distro, and here's why:
- 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).
- Eases installation and testing.
Very important. Again, one place where OS X wins is the `it just
works' measure. They have a limited amount of hardware
- Out-of-the-box solution.
I think we could learn a lot from BeOS 5 Personal Edition in this
respect. You could boot from the CD, you could copy the image to your
hard drive and boot from Windows 9x (this kind of thing isn't possible
with Windows NT, unfortunately), or you could create a partition on
your hard disk and install to that from within the live image. The
time from getting the CD to running the OS was under a minute. The
amount of time between starting the OS and having it installed was not
much more (the ability to install from the LiveCD, rather than having a
separate install routing is also something we should consider - don't
make users wait an hour or so from getting the CD to seeing what the
system looks and feels like).
I would say some kind of a LiveCD would be a great solution.
Definitely. Keep the barrier to entry as low as possible.
I'm in favor of either Linux or a BSD; Linux because it's got a larger
developer community and the name "Linux" is better for marketing, *BSD
because it's got a more cleanly integrated base system and a smaller
development team which might be easier to coordinate with.
I would personally favour NetBSD. The base system is very clean, small
and customisable, and it provides a working and tested system on a
large number of platforms. I would imagine that a significant
proportion of our potential audience would be Mac users, so having a
working Mac/PPC version (and LiveCD), as well as x86 would be an
advantage. Focussing on x86 to start with might be a good idea, since
it is the largest potential audience, but picking a base system which
is consistent across multiple architectures is definitely a good idea
long-term.
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.
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…
Maybe a good conversation for this is to think "if we had only one
target platform, what kind of things could be possible that we
couldn't do otherwise?"
Network, power management, etc. configuration utilities (these would be
possible for a DE, but a lot more work since they would need to wrap a
variety of different low-level features rather than just one). Fast
user switching, security systems such as keychain (easy to implement on
NetBSD, Solaris, FreeBSD or Linux, since they all provide some
mechanism for authenticated IPC, but much harder to implement in a
cross-platform way since each mechanism has slightly different
capabilities and syntax). Customised init system for fast boot (I
don't imagine many people will be using Étoilé on a server, so fast
boot-to-GUI is important), consistency, ease of support / testing.
Dependency on mechanisms that don't necessarily exist in some
platforms.
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.
Additionally, let's ask "what extra work will go into supporting a
full OS instead of just a DE?"
That depends on the base system we use. If we chose Linux, then it
depends if we are doing a Linux-from-scratch approach (in which case we
have a large amount of work to build and test packages), or basing it
on a specific distribution (in which case we have to ensure our
packages work on that system, and probably, at least, create a custom
installer and liveCD etc.) Even if we don't go for a whole OS, I would
imagine that we would want some kind of LiveCD, so that effort still
exists.
Once we have a working system, then it should just be a matter of
importing changes from the upstream base system and performing
regression testing (something we would have to do anyway).
============================================
THE INTERFACE
============================================
- 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…).
- Spacial interfaces can be extremely painful and lead to a lot of
windows on the screen. I do like 1 window for 1 folder -- that's a
good idea, as is keeping the location and view of a specific folder
consistent. Browser navigation is really slick for deep hierarchies --
we just need to find a way to unify the two concepts. Or...
Agreed. I find spacial navigation very good for folders I manage
myself, but not for system folders etc. The way the OS X Finder
switches between the two is really messy.
- Ditch the ability for regular users to create folders altogether
and put all files in one spot (probably their home folder merged with
a Shared folder for all system users). Make the workspace manager an
awesome searching and filtering tool. Add buttons to the workspace
manager for "Music" or "Photos" or "Letters to my boss since last
Tuesday" or whatever, and just make those shortcuts for queries (live
search folders). Never use a Save dialog again -- when you make a new
file, just give it a name and it's automatically added to the user's
home folder, ready to be searched on.
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.
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.
============================================
THE TECHNOLOGY
============================================
Here are some random bits of other technologies or ideas that might be
inspiring.
…
Where I think Raskin goes wrong is that he tends to favor a more
command line approach, instead of the more intuitive approach of
direct manipulation. He also tends to look at files as textual
elements when, for me, the majority of what I manipulate every day is
graphic. Some of his good points:
Raskin does (did) tend to be very text-centric. A lot of his ideas
really only make sense in the context of someone manipulating text, and
some are just plain silly (the idea that an incoming email should be
pasted into the current document is just insane, and would completely
destroy flow).
- Eliminate model interfaces as much as possible.
We should also eliminate modal interface :)
- Build a history of selections. If I make a selection in a body of
text, that is selection 0. If I make a new selection, the new
selection is numbered 0 and the previous one is numbered 1. This goes
on for as many selections as we can technically handle. All the
selections might be badged by their historical number (or some other
visual method). Swapping two pieces of text now becomes insanely easy:
just have a menu item labeled "Swap". This is far superior to "select,
cut, paste, select, cut, find previous insertion point, paste".
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.
- Make alerts that don't require interaction to show up, then fade
out, and keep track of all alerts. You know the JavaScript alert()
function? Horrible. It pops up with some text and an OK button, and
forces the user to disrupt what they're doing to get rid of it. I'm
using Growl < http://www.growl.info/ > now for alerts on downloads and
new emails, and it is exactly how alerts should work: it shows up, it
stays for a bit, it fades away. Elegant, informative and unobtrusive.
Now if only we could build a simple way to pull up old alerts when
you're busy doing something else and the alert fades before you get a
chance to read it, it would be perfect.
I believe Apple have a patent on this, but it's still a very neat idea.
As Raskin says, things should only require human interaction if they
actually require human interaction.
- 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
