Le 7 avr. 05, à 13:33, David Chisnall a écrit :
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).
I agree on the concept, yes. First, we should focus on the Étoilé DE,
then we'll work on the Étoilé OS (e.g, instead of doing OS-specific
configuration tools and trying to have them on all OS, we'll just focus
on one OS, build the right config tools for it, and create a live cd
from it as well).
But frankly, an Étoilé OS is a bit far I think, we should first work on
Étoilé DE 1.0 :-D
- 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
Yes, although for a beginning a live cd approach is probably the best
thing we can do -- easy for people to test, easy to install, and easy
for us to setup properly. Look at the GNUSTEP live CD: the environment
"feels" more polished than my own average installation of GNUstep ;-)
-- just because everything was properly setup, lots of gnustep software
bundled, while I didn't bother to install some software or doing some
configs...
- 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 believe it's something already possible with the current GNUSTEP live
cd -- you can just use the morphix installer (available when the system
is up, but there's perhaps an option to install directly from the boot
prompt?). And when loading the live cd on windows (or mac) you have
access to documents, etc., so really I think we should just
reuse/collaborate with gürkan's live cd.
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…
Well, anyway we're a bit early to speak about that imho -- first we
should try to make étoilé DE, then after try to configure a nice livecd
with it. We'll see what kind of OS for the live cd we'll use...
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.
yes. It would be interesting to use something other than linux if the
advantages are there, but in order to provide a live cd, the simplest
and fastest possibility is indeed to just take the GNUSTEP live cd and
build on top of it.
============================================
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 would advocate a tabbed shelf/panel
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…).
hehe :-) cool !
(I should be able to work a bit on gnustep now that my own paper
deadline was in the end removed/deplaced.. ;-)
- 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.
well, the OSX Finder is for sure not a good example :-)
- 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.
Exactly. That's why a "flat approach" (every documents as a bundle --
so you can easily associate metadatas to a document -- and all the
documents in a same directory/repository) could be interesting; not
that it prevents users to organize their documents hierarchically, they
can of course continue to do that; but as the hierarchy is thus a
simple view on top of the "real" content, it's not the only view the
user can have (he could easily switch for a date-based approach for
example, or use different "tags" on the documents instead of putting
them into a "directory" ...).
I actually think that, while a system-wide metadata support could be
good, it would probably be enough to limit that "flat approach" to the
user's directory / user's documents. We could add some modifications in
NSDocument to handles that transparently for example. As a user, I
don't care too much about the system files, and have not a lot of use
to class them or associate metadatas with them, while I have a lot of
interest of doing that for my own documents ! (of course, I still agree
that having such a feature for the whole system could be interesting
for administrators, for example, but hey..)
- Eliminate model interfaces as much as possible.
We should also eliminate modal interface :)
yes :-)
- 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.
Would it be solved by a "pasteboard viewer" showing the content of the
pasteboard and keeping an history ?
- 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.
On screen display.
- 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
Yes, there's a lot of things possible if we focus on one OS instead of
wanting a cross platform desktop.
--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke
