bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

X and other visions


From: soeren . d . schulze
Subject: X and other visions
Date: Sat, 12 Jun 2004 14:40:02 +0200 (MEST)

Hi hackers,

We have discussed it on IRC and that has influenced this posting, but IRC is
bad for long discussions - so I'm writing here.

GNU/Hurd is quite an unfinished system, so it has rather the chances of
implementing a *clean* UI than any other system with an already existing and
working UI - a new (the existing one is even worse than at GNU/Linux) UI has
to be implemented anyway.

Don't misunderstand me, I'm not pro UI monoculture.
Several UIs may exist from the user's perspective, but that doesn't have to
mean they can't cooperate.

How I would technically realize this:
A graphics hardware driver runs from startup and is attached to some ttys
either as Framebuffer in GNU/Linux or as X session. Here we have to
distinguish between an X server and an X session. Currently you have to
start a new X server for each new session. According to my idea, it can be
started as a daemon on startup or whenever it is used.
I know about Xnest and I think it's a good idea, but it does not fix general
design lacks in XFree86.

So when all the displays (text or X) are controlled by an underlying tty
driver, this enables an other feature to be realized:
If something like an error, that was not caused by user interaction, happens
on a display you are not working at, you can be notified about it.
Either provides your UI a notification callback that opens e.g. a
notification window, or is the display simply switched by the underlying tty
driver.
Such a feature would solve notification problems when you switch the
display.

We are reaching another point that has been solved insufficiently in
GNU/Linux: special rights for console users
I do not exactly know how to realize it, but let me simply describe what I
mean:
Things like these are typical tasks for a console user:
- turn off the computer (on desktop machines)
- access the sound card and the mixer
- start X sessions on the local machine
The current console user(s) should have almost root rights (regarding
hardware access, so not installing software), on the other hand the network
users should have less rights (it usually doesn't make sense when a remote
user is permitted to turn the volume up and to play an annoying sound ...).
So
1. the tty driver has to provide information which tty is currently used
2. the file permission management has to be improved (it has to be improved
anyway).
In the ideal case, it should be impossible for a console user to do things
that require console access over network.
The second point could be tricky because possibly some standards have to be
*extended* (in worst case broken).

These are only a few points how I think the problems of UI multiplicity can
be solved. We will reach some more points during the discussion.

Please do not ignore or flame down me because I'm not so used to hacking
that stuff. I think I'm experienced enough to GNU/Linux to know how a
realization should not look like, and I'd like GNU/Hurd to be better.

I also know about KGI/GGI and I think it's a really good idea if it will be
realized consistently, but it is only a part of the solution.

Sören

-- 
+++ Jetzt WLAN-Router für alle DSL-Einsteiger und Wechsler +++
GMX DSL-Powertarife zudem 3 Monate gratis* http://www.gmx.net/dsl





reply via email to

[Prev in Thread] Current Thread [Next in Thread]