Before I get into the details, let me say that I have toyed with
creating two different GNUstep-based Linux distros in the last year and
a half. The first was called GoboStep, based on GoboLinux, which never
really got off the ground because GNUstep wasn't really mature enough at
the time, because nobody else was interested in GoboStep's admittedly
very different (intentionally) FSH, and because there was no cohesive
desktop environment effort at the time. The second, which was to be
based on Arch Linux, never really got off the ground the way I wanted it
to, but I state this here because I've given a lot of this stuff a lot
of thought in the past, and I'd like to give my rationales for my
beliefs here.
David Chisnall wrote:
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.
As do I. I also agree that this is what makes OS X so reliable and
cohesive.
- 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, and we don't have that luxury. This complicates things immensely.
- 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).
Yes...I envisioned exactly this as well. The installer CD *IS* the
LiveCD, and the LiveCD is the installer CD. There is no difference, they
are one in the same. It just makes sense this way.
I would say some kind of a LiveCD would be a great solution.
Definitely. Keep the barrier to entry as low as possible.
Indeed.
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.
This is where people start to disagree. I strongly believe that any
desktop OS should be x86[-64] Personally, I have nothing against FreeBSD
or NetBSD, but, in my opinion, for a true GNUstep-based personal desktop
OS to be competitive, it needs reasonably competitive hardware and
peripheral support. This is where the BSD's start to fall short. I
personally really really like DragonflyBSD, and wouldn't mind seeing a
GNUstep-based desktop OS built around it, but its hardware support is
also lacking. Most people who own PC's these days have either an ATI
Radeon or NVidia-based GeForce-series graphics accelerator. If a given
OS doesn't have support for hardware-accelerated OpenGL graphics (for
both ATI and OpenGL) then, while it may be very useful in plenty of
other circumstances, as a desktop OS candidate it's a non-starter. I
expect to be disagreed with here, but I believe this very deeply.
This criterion rules out both NetBSD and OpenBSD as options at the
current point. FreeBSD and possibly DragonflyBSD are still options, as
well as Linux.
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, by design. They are of the "do one thing, do it well" first mantra,
as am I.
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…
We can all dream, but it won't get us anywhere. Expecting HURD to be
functional in the next decade is like expecting world hunger to be fixed
tomorrow. Ain't gonna happen. We have to be realistic.
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?"
Really good hardware support. I would never participate in a
GNUstep-based desktop OS project which I would not use as my primary
desktop environment. That requires that I have hardware-accelerated
OpenGL (in my case, nvidia)
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).
Not really. This is what Hardware Abstraction Layer aims to fix. Read
about it at http://www.freedesktop.org/wiki/Software_2fhal since it's
outside the scope of this thread.
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.
You have to be careful when you use the term "cross-platform'...I
presume, based on your usage, that you mean "cross-OS" and not
"cross-architecture" but can you verify that for me? I also agree that
fast boot-to-GUI is also extremely important. Matt Rice did some work a
while back on a parallelized init system, and folks at IBM have also
done the same. There are several options under both Linux and BSD here.
We should go further, and say that any Étoilé-based desktop OS should
*NOT* be a server. That doesn't meant it can't have a web server or
anything like that, just that it wouldn't under the default install,
because it's a desktop OS, and nothing more.
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.
This assertion is completely false. Take a look at FAM. It's completely
cross-platform. FAM works with IRIX, Linux, *BSD. (FAM is essentially
for filesystem-monitoring what HAL is for hardware) Under Linux 2.6, it
uses kernel-level mechanisms to transparently watch file access &
modification. Linux does (and has, for some time) had exactly the
functionality you refer to. It just goes to show you that you
established a view of Linux at a fixed point in time and probably
haven't investigated whether or not certain things have changed. This is
kind of dangerous.
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.)
Well, I've also thought about this a lot, and while an LFS approach
would be nice, I personally think it's a waste of time. We wouldn't
consider doing this with any BSD, so why would you consider doing it
with Linux? Customization of a pre-existing distro is perfectly fine,
and saves us a lot of time. There many, many, many people working on
Linux-based distros, and to be so presumptuous as to reject their work
and claim we can do something better is not only probably completely
untrue, it's unachievable. an LFS-approach also means that if I get hit
by a bus after having written it, or get married and have a kid, or any
other of a number of real-world related things that might require my
undivided attention for months or years, it's much much harder for
someone else to pick up where you left off. This is what happened to
LinuxSTEP (which was essentially LFS-based)
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.
Indeed. There's already a good Linux-based GNustep live CD, made by
Gürkan Sengün (see http://livecd.gnustep.org) which we could at least
consider using as a basis for further development. It's Morphix-based.
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).
Yes, there's a lot more to it, but that's one step :)
============================================
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…).
Cool. You'd better. :)
- 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.
Personally, the way I work requires both. Windows supports both. I use both.
- 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.
Yeah...I kind of think that stuffing this down your potential users'
throats is not going to make you many fans. I want to manage my own
files in folders, and it bothers me when iTunes insists on doing it for
me, for instance. There's more than one way to organize your music.
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).
While I agree partially with this, I don't think the file/folder
paradigm needs to be thrown away completely either. most modern
Filesystems support Extended Attributes and Metadata, and that should be
used. I see your solution/suggestion as throwing away the baby with the
bathwater.
Current systems make it very different to have multiple, independent,
views on the filesystem.
Not sure if I agree here.
[snip]
- 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.
Interestingly, this is exactly how Microsoft Office 2003's extended
clipboard system works under Windows. It works well, but I have never
personally found the need for the feature.
- 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.
Yes, we need to port Growl to GNUstep, but unfortunately the author/lead
developer and I had a rather serious falling out (after I knew him
online for a year or two) where he basically said "GNUstep is going
nowhere, sucks ass, and you are an idiot for pursuing what you believe
in") and as a result I will no longer be doing any work on porting Growl
(I had done some, but it's been lost in a hard drive crash a while
ago) I would encourage others to port it, however.
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.
Agreed. As for the patent, it would have to be a design patent, and I
don't know that it's actually valid, since Microsoft does this also with
"baloon system tray popups" which disappear after a few seconds in a
very similar manner.
- 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
Should what?? Your e-mail was cut short.
This sort of functionality is very easy with Linux's generic hotplug
subsystem, and AFAIK the basis for what you speak of already exists in
the Linux kernel.
