[gold-devel] Here we go, folks

[Adam Martin]

All,

On Mar 3, 2007, at 11:33 AM, Justin Hibbits wrote:

> Now, the time I've been trying to bring for the last 2 years:  What  
> do we want, what are our goals, and what do we need to obtain them?
>
> Here's what I know so far:
>
> - Object system (no files, just objects with forks, or whatever) --  
> have to flesh the behavior of this out.

	All items in LSD should be Objects.  Processes, Devices, Anything,  
everything.  If you access it in any way, it is an Object.  Threads  
are "objects" too, for the sense of delivering Events.  We need to  
flesh out this behavior in a separate document.  This is more the  
lower level technical stuff.

> - authd is a 'trusted' application, it has the following purposes:
>   - Spawn 'init'
>   - Spawn session login manager
>   - Spawn authentication handlers
>   - Spawn session manager
>   - Handle authentication and spawning processes under other users
>   - Shutdown the system
>
>   - authd doesn't use or know about named objects (URI-types), and  
> should never know, for security reasons.

	Authd may need some kind of "object-aliasing" then for it's  
important objects.  Or a config file with this information in it,  
passed from bootloader.  Again, this must be outlined in more detail,  
in a technical analysis.

> - I think we should break libSystem into two parts: libSystem and  
> libUser, to provide core system interfaces and user-only interfaces.

	A good idea.  But why this split.  Maybe we should look at our  
design goals, and see if splitting libSystem into more than just 2  
libraries is the right goal... maybe we want several dozen libraries,  
or a library for each class like Java.  We need to look at what we want.

> Now, we need to decide the following things:
> - What do we want?
> - How do we get there?

	I think we all want: "The perfect system", as ill-defined as such a  
goal is.  We need to get there, by finishing the "phase-1" experiment  
of this system.  Specifically -- a kernel with object-interfaces, a  
libSystem with URI support, authd, and the general Gold idea.

	We all want a programming interface that gives us abstractions for  
everything, and a "rich" toolkit of system objects so that we can  
make software easily.

	So below I'm going to go into what makes a system good, and usable  
to me.

> Specifically:
> - What does LSD provide, and consume?

	LSD will provide a set of asynchronous APIs for object access in two  
ways:  Event driven, and Page mapped.  LSD will provide scheduling  
services, threading services, memory manipulation primitives, and  
more.  No networking, no multimedia -- System provides this.  It will  
require the process to select portions of its address space for  
kernel interaction pages.  It will consume user requests from these  
interaction pages, and return information in some of them, as well as  
perform page mapping and process creation requests.

> - How does the system start up?

	The bootloader will load LSD with some information:  A GUID for the  
configuration file for Authd, and the GUID of authd itself.  LSD will  
boot, and launch Authd, passing it the GUID of the configuration  
file.  Authd will do what it needs to do.  Authd will start to launch  
user sessions, and daemon services.  A graphical login will be nice,  
but I believe this must be optional (default can be GUI though.)  We  
do want textual feedback for debugging.  And logs... log EVERYTHING.   
All output to "text console" by any application in the bootup  
procedure should be directed to a log.  We may want a log  
infrastructure like *NIX, but with different semantics.  We should  
delve deeper into the log aspect at some point.

> - How does a user session work?

	At the most basic level, the user will authenticate himself, and be  
presented with his work environment.  This work environment should,  
ideally, save the last operational state of his work.  In other  
words, if you last had open 3 text documents, and 2 web browsers,  
this will be restored such that it would appear that you never left.   
At the technical level, we may wish to implement this with a process  
snapshot primitive.  The web-browsers should be open to the same web- 
pages, with the same scroll positions and everything, just like the  
user never left.  Consider how your environment looks after you  
"unlock" it from screensaver or "sleep".  This is the effect the user  
should be presented with at login.  At logout, the user may be  
offered the option to quiesce all his work -- such that he is  
presented with a virgin login next time.  (I.E.: Close all programs,  
before logout.)  At the shell level, it would be nice to have the  
user offered an option to continue a previous interactive shell  
session, or to spawn a new one.  It may be nice to have a command  
which saves current shell session state to a file, for later reuse.   
Think like pushd/popd, but for the whole shell state -- environment  
variables, history, running jobs, etc.

	The system must provide a comfortable interface for the user.  All  
graphical widgets, no matter how trivial, must have some form of  
interactive online-help.  Most buttons, no matter how trivial, even a  
window-close button, should have a tool-tip.  Trivial tool-tips can  
have massively long delays.  GUI interfaces should be configurable,  
so that the session layout can be made comfortable.  Examples of  
things with extant systems which offend me, and make the system too  
rigid: MacOS's menubar must be at the top.  MacOS doesn't let you  
move the window-manipulation widgets.  MacOS requires resizes only  
from the lower right corner.  Windows doesn't let you move window  
manipulation widgets.  Windows doesn't let you move the start menu,  
within the task bar.  Windows doesn't let you move the time display  
in the task bar.  Windows has nasty evil modal windows.  X11 requires  
users to pick from myriad environments all incompatible.  X11's user  
environments focus too much on eye candy to appear like windows.  KDE  
doesn't let you have multiple desktops laid out in multi-dimensional  
arrangement.  Enlightenment themes don't let you relocate buttons.  I  
could go on.

	The user session is his work environment.  It must be both  
comfortable and customizable.  The watchword we can call this is  
comfortomizable (if you want a new buzz word.)  User session is how  
the user experiences the system.  Above all else, it must reflect  
both the underlying power, and underlying simplicity of the system.   
Go look at a few video game interfaces, for consoles.  They provide a  
very concise user environment for manipulating stored data, selecting  
programs, and even within games selecting levels styles and more.   
Although the environments are not customizable, they are both  
intuitive and "slick" but not in a flashy way.  They provide right at  
your fingertips all the capabilities you need to get the work done.   
Granted that general computing has far more options and  
possibilities, but we should strive to have a work environment which  
users can manipulate with ease.  Despite my criticisms, MacOS X and  
Windows XP/Vista provide a few examples of good things too.  Even  
trivial things like "Dashboard" are not to be overlooked.  Dashboard  
provides users with a workspace to "store" some graphical widgets  
which provide them the information and functionality they need in  
daily computer life, in an on-demand, and fast way.  I just recently  
started using it, and I have on dashboard: 3 terminal widgets, a mini  
web browser, an iTunes controlling mechanism, an Analog clock, a  
calendar, a stock ticker, a weather reporter, and a widget which  
tells me how many times I've accessed dashboard (as a way to gauge if  
I use it as much as I think I do...  so far, yes.)  Why do I have  
those things?  I require demand-access to a terminal at random times,  
to a web-browser at certain times, and the remaining items let me  
either control or observe the state of computer and universe as  
needed to make my life easier.  A good system should give you this  
information when you want it, how you want it, and make it easy to  
"program" it to give you this information.

> - What do we provide to users to get their work done?

	This usually depends upon a user's work, and so I will describe what  
I would like to see for each of my work habits.

	Sometimes I'm just surfing the web, and using IM, and playing  
music.  Most of the current systems are adequate to good in this  
department.  Some killer features would be a set of improvements to  
tabbed browsing -- Let tabs be fully refactorable, and attachable.   
Most guis let you create, and detach tabs.  Sometimes you want to  
merge a tab into a window too.  This usually involves a process of  
spawning a new tab, and opening an already open page in that new tab,  
and closing the old tab.  All applications should have tabs.  Someone  
recently wondered aloud at FSL why window managers do not have tab  
support.  Maybe we should consider this.  If the windowing  
environment provides tab operation, and maybe even "recursive  
tabbing" -- that is tabs within tabs -- we might have something to  
offer the user in fashion of usability.  Music manipulation, just  
recall all the associativity discussions we've had.

	Working on documents -- it might be nice to have some kind of  
automated citation system.  Oftentimes I find myself writing things,  
and needing to give citations or footnotes.  While current editors  
provide this functionality, it might need to be more accessible.  It  
would be handy to drag-and-drop a number of extant documents into the  
editor, as citable works, assign them a code, and maybe even have a  
GUI interface for selecting a quote from these documents, having it  
auto-formatted according to a plugin based set of rules for things  
like ... and such.  The works cited or references section can be auto- 
generated this way too.  This will be very nice for academic and  
professional writing.  An integrated keyword search system for the  
document editor might be useful too.  Document searching should be  
integrated too.  What Apple is trying to do with spotlight is a good  
start, but done wrong.  Metadata indexing should be done on the fly,  
as created.

	Software development - The system should come with a good version  
control system integrated, like subversion.  We'll need it for source  
code updates anyhow.  The version control system integrated into the  
editor is nice.  Many IDEs do this.  We should allow the editor to of  
course be keybinding adjustable for the likes of VI zealots, emacs  
fools, windows weenies, and more.  If you just LOVED the VMS editor,  
you should have that binding in our gui.  We need a gui manipulator  
for software objects, with code generation.  Think something a bit  
like UML diagrams with code generators, but with the added capacity  
that already existing libraries are referenced properly, and can be  
chained together to create mechanisms.  Software testing should occur  
within protected sessions to not accidentally clobber anything the  
user/developer finds important.  Instead of requiring two logins of  
each programmer, one for development and working, and one for  
testing, we should provide a sanitized testing environment.  A  
debugger with variable history tracing would be nice -- I could  
select a variable and see all the states it has had over the runtime  
of the program, what lines of code changed it, and related  
information.  Instead of watching it change, I can see the endgame,  
and roll back to the first time it went wrong.  Besides all standard  
library and gui toolkits for creating new applications, a debugging  
object or library framework may be useful.  This library would behave  
like a profiled version of the standard library, and also emit  
warnings for things that seem a bit unkosher.  The library could be  
instructed to track states, rewind the program, replay sections, much  
like a debugger.  (This could even be the debugger.)  An editor with  
folding text will be a must, obviously.  At some point, we should  
also discuss kernel development facilities.  Build system should be  
automatic.  When creating a new source file, as you add dependancies,  
it will auto-generate lines in a file which your makefile can source,  
or ignore.  (We want to help the user, but not force him to do things  
our way.)  An ability to patch a running program with a new version  
of a library may be nice, but results will be slightly  
unpredictable.  If you're not sure what features to provide to a  
programmer look at modern IDEs.  We want those features, but we don't  
want to beat the user over the head with that interface.  Designing  
and implementing GUI applications should be trivial, as discussed.   
Remember the 6-click-spreadsheet goal.  Creating new widgets with  
extended behavior over old widgets should be trivial -- Click on a  
widget, click on extend, give a new name, and write the extensions  
right there.

Overall user experience -- Separate the functionality and features  
from the interface.  Just because someone wants a feature or function  
doesn't mean he wants it through YOUR preferred interface.  Each  
function and feature should be easy to rebind to another interface or  
mechanism with trivial ease.  If a "Windows Power User" (read --  
someone who knows to defrag often, keep the system up to date, and  
knows not to fuck with the registry, unless absolutely required...  
and has installed programs himself, and removed them) cannot figure  
it out, it may be too hard.

User environment mandatory functionality -- All things that modern  
guis can do should be available to the user.  If a user so desired,  
he could setup his environment to LOOK like his favorite environment  
he has used in the past.  A user needs the capacity to open files,  
navigate the file system tree (this would be the file:/// URI  
structure), and do all tasks we take for granted.  Things like where  
the menubar and clock and such are located... these are but mere  
bagatelle; we must give the user a functional interface toolkit.   
What we can then do is also for first login offer the user a  
selection from extant popular interfaces: OSX, Win2k, KDE, etc.

> That is all,
> - Justin

--
ADAM David Alan Martin