[Top][All Lists]

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

Re: X and other visions

From: Sören Schulze
Subject: Re: X and other visions
Date: Mon, 14 Jun 2004 13:34:41 +0200 (MEST)

Rian Hunter wrote:
> On Sun, 2004-06-13 at 10:34, "Sören Schulze" wrote:
> > Alfred M. Szmidt wrote:
> > >    I know about Xnest and I think it's a good idea, but it does not
> > >    fix general design lacks in XFree86.
> > > 
> > > Fixing XFree86 is kinda out of the scope of GNU/Hurd...
> > 
> > Of course.
> > AFAIK GNU/Hurd will mainly support GGI/KGI instead.
> > (doesn't mean it won't support XFree86 any further, but I don't know
> ...)
> AFAIK kgi/ggi are just graphic interface layers. Not window systems, If
> someone ever gets around to actually providing a KGI type hurd server,
> the X server will run in pure user space on that, instead of providing
> video drivers (that have always belonged in the "kernel", microkernel +
> servers for us). We'll always need X (or some other maybe newer
> (fresco!) windowing system). Every desktop O/S needs a window system
> (for multiplexing graphic applications within a single console).

X may be outdated, but many programs use it.
And please note there's a difference between XFree86 and X(11R6).
Do you know about XGGI?

> > >    Things like these are typical tasks for a console user:
> > >    - turn off the computer (on desktop machines)
> > > 
> > > Also a typical task for a remote user; atleast w.r.t. to rebooting
> > > which is essentially the same with some minor details.
> > 
> > I don't think it is nice any user from network can reboot the system.
> > OK, it may be useful if the system I/O is blocked and you have to
> reboot,
> > but in this case the admin should do that anyway.
> I think you are forgetting that this is UNIX(-like) and not Windows or
> Mac OS (traditionally single-user systems). It is perfectly alright for
> a root user to reboot the machine whenever he wants or requires, albeit
> a little unfriendly. And since I last checked only root was able to
> reboot or turn off the system, not "any user". Please don't forget the
> goal of the GNU project.

What are you referring to?
Of course root is supposed to have unlimited rights on a system.
But maybe the console user should have similar rights.

> > >    - access the sound card and the mixer
> > > 
> > > Ditto.  I infact use the mixer and play songs remotely each and
> > > everyday.
> > 
> > You play songs on computers of other people? May be a nice surprise ...
> Having a raw audio device is comparable to having a raw framebuffer
> device. That's why X was created, so maybe you should use a sound server
> (or port one) that multiplexes sound output or integrate sound into the
> console. So that changing your volume doesn't changes others, or playing
> songs, doesn't sound on other's consoles.

Playing stops when switching to another tty?
Maybe a nice optional feature.
Referring to software mixers:
I'm afraid the most unified sound interface is still the raw device. :/

> > > Take the example of file-systems, one could quite well argue that one
> > > needs console support to set a file-system translator on a "device";
> > > since a physical user put the "device" into the system.
> > > 
> > > But this "device" could be a hard-disk, or just a plain file.  Where
> > > would you draw the line in this case?
> > 
> > Your example is simple to solve:
> > Nobody but root should usually be permitted to set a translator to a
> > partition of a physical hard disk.
> > So we simply deny any direct access to the HD.
> > (perhaps that doesn't work how I expect it to - excuse my lacking
> knowledge
> > about the Hurd)
> Please Please Please Don't forget the goals of the HURD! It defeats the
> purpose of the HURD to only allow root to set translators.

It's (almost) completely system-independent whether users should have raw
access to the HD, which includes setting translators.


"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info

reply via email to

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