GUI systems

[Kragen Sitaker]

Norm Hardy writes:
> Is there a source of information on the LCD of the display hardware?

Well, the LCD is that there's a framebuffer you can write pixels into.
Unfortunately, that's really slow.  You can add features: blitting,
lines, circles, filled circles, stipples, filled polygons, etc. etc.
etc. to make your video card faster; you have to haul them all the way
up to the user application to get any use out of them.

So for any particular optimization (mipmapping, say), you have at least
three choices.  You can ignore it, which means it doesn't get used, so
it might as well not be there --- it doesn't help your performance.
You can provide it in your display system, which means you have to
write a software version for hardware that doesn't support it.  Or you
can provide access to it in your display system, but only on hardware
that supports it, which means every single application that uses it has
to make sure it's there and either use a substitute or die.  This means
your user applications become impossible to test.

New hardware optimizations appear every six months.

> Is some display hardware able to do its work in system RAM, or at least
> deliver its work product in system RAM? If so the display card just becomes
> another processor accessible to domain code via capabilities to prepare bit
> rasters for delivery, by capability, to the screen. This sounds like a lot
> of work.

In general, the interface between the CPU and the display hardware is
much slower than the interface between the display hardware and its
framebuffer, often by one or two orders of magnitude.

> A few year ago I studied the X windows protocol and it was oblivious to
> security. Any task could corrupt any window. That doesnnot mean that a
> capability version could not be invented.

I understand that various Unix vendors sell an X server that supports
security compartment labeling as part of their "trusted" operating
systems, i.e.  systems that provide Orange Book mandatory access
controls.  I wonder if their protocol work could be used for this.

I'm not sure it matters *that* much, though; there are many programs
that could benefit from EROS's better security model that do not need a
GUI, and there are things like Xnest and VNC as a sop to make it
possible to display programs that should be confined.

> For paranoid customers it would be good to have an alternate bare-bones
> display ability, accessible by a "secure attention button", via which he
> could talk to the TCB. This is sort of like the Unix systems that may dump
> you into ROM code.I wasn't thinking that bare-bones, however.

That would be very useful.

> The security problems of Unix are in parts of the Unix architecture
> that legacy code may have been closely adapted to.

Agreed.

> The result will probably be an insecure system that is slower than Unix.
> (Slower due to Unix emulation)
> At least some of the legacy application must be redone in order to
> gain security advantages of Eros/Keykos.
> Great gobs of legacy code may remain unaffected.

I think it's possible to gain *some* security advantage without
modifying dusty-deck applications at all.  

First, various processes that are root only because they need to bind
to low ports, read special files, or reconfigure network hardware, can
be turned into unprivileged processes bearing a single special key
allowing them to bind to whichever port they need to.  (On my machine,
this covers pump, syslogd, klogd, some of inetd, and some of sendmail.)

Second, various processes that need to run tasks on behalf of various
unprivileged users can be given a capability to become any unprivileged
user.  (When we rewrite them, users who want those processes to be able
to become them will explicitly grant limited capabilities to those
processes.)  (This covers the rest of inetd and sendmail, crond, gdm,
and login.)

Third, the more flexible capability architecture will reduce the need
to circumvent the security system.  At the moment, for example, I'm
running minicom as root, because my /dev/ttyS0 is root.tty mode 600,
and I'm nervous about changing its gid to "modem" and adding myself to
that group; I'm worried I might break something.

Fourth, ordinary users can run applications in a restricted environment
more easily and effectively.  Netscape, for example, should run in an
environment where it can't read any files I don't explicitly grant it
permission for.

Fifth, as you pointed out, this extends to installing applications in a
restricted environment.  This can be done without rewriting the
applications --- just figuring out what needs to appear in their
restricted environment.

Sixth, every user can have a private /tmp directory --- indeed, an
entire private filesystem.  This is especially useful for software that
unreasonably wants to be installed as root --- rpm-installed and
dpkg-installed software is especially bad about this.

Jonathan Shapiro writes:
> While X has many flaws, the low-level rendering primitives were very
> carefully thought out with respect to what happens (e.g.) when two objects
> have a common edge and are filled with different colors. Setting aside
> high-level X, there is merit to supporting the rendering system.

I am not experienced enough with Xlib to be able to say whether this is
correct or not; however, some people who I would think should know
(e.g. jwz.org) think X's rendering primitives are really screwed up.

Shawn Rutledge writes:
> I don't think an EROS system ought to directly do graphical stuff.

I agree.

> That's too old-fashioned, and EROS itself should concentrate on being the 
> best darn distributed-address-space capability system there is rather than
> being good at everything like GNU/Linux-based systems try to do.

I didn't know EROS had become a distributed OS.  Are you thinking of E?

>  With
> as many Linux developers as there are, they are just barely keeping up with
> the innovations of others, and not coming up with really new ideas often
> enough.

Linux became operational and usable a few months after the project was
started, in 1992.  Its user base has doubled roughly every year since
the ten-thousand user mark in 1993.  This is because Linux tries very
hard not to keep up with innovations or come up with really new ideas.
By contrast, the GNU Hurd became usable in 1998, fourteen years after
the inception of the GNU project and some five years after the design
of the Hurd itself.  It still has fewer than ten thousand users ---
precisely because exploring new ideas was the top priority.

EROS is already fairly radical compared to Linux or even the Hurd.

> Client-server GUI systems are the future (despite being a fairly old idea).  

Agreed.

> But, OpenGL might be a valid on-the-wire protocol to replace X.  Maybe
> it would need some extensions for handling events from input devices.

There is already an OpenGL implementation of X, so it meets my
approval (not that anybody needs my approval, of course).  My
impression of OpenGL is far more positive than my impression of X.  :)

> It's important to preserve the ability to do accelerated graphics in
> hardware rather than always using pixmaps as the lowest common denominator
> IMO.

Agreed.

(in an earlier email:)
> GNUStep just runs on top of X, right?  It's a framework, not a protocol.

It runs on top of Display PostScript (or Display GhostScript), which
can be implemented as an X extension or standalone.  I also like
PostScript much better than Xlib.  However, many more portable current
applications use Xlib.  (Even more applications use Win32 GDI, but I
think porting most of those applications is likely to be too
difficult.)

> What do you mean by smalltalk?  Does it have a standardized UI system?

Yes.

> I would counter-propose Java in that case, as being more popular...
> too bad Swing and AWT are both so suboptimal in a lot of ways.

Yes.

> Anyway, there are always
> needs for custom UI elements beyond the common ones, for specific
> applications.  This is what bothers me... it's hard to make them 
> device-independent.  Applications like word processors, drawing apps,
> information storage and retrieval apps, etc. could have UI's represented
> in device-independent ways, but it's always possible to think of something
> that doesn't fit the existing paradigm.

This is a very hard research problem.  Making the success of one's
software dependent on solving a very hard research problem
significantly decreases the chances of its success.

I think this is a very interesting project, and I will certainly watch
metawidgets.org when you build it.  I just don't think it should be
adopted as the standard EROS drawing toolkit until after it is proven :)

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either.  :)