Re: X and other visions

[Sören Schulze]

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 ...)

> 
>    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.
> 
> Anything wrong with how it does it now?

It does nothing now, and there _is_ something wrong with that.
You may be lucky you're currently using the UI where the error appears, but
if you aren't, you may wonder why something doesn't work because you haven't
seen the error message.

> 
>    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.
> 
> This is usally called a log-monitor.

I don't doubt you prefer logs instead of pop-up windows.
But some people (especially those who are used to *Desktop* OSs ...) may
think different.
But moreover there's another problem:
If that software writes to syslog, you have to

1. enable read access to syslog, which may be not what you want for security
reasons, and
2. specify the receiver of the message - may be stupid if you are flooded by
error messages of other people - or maybe they don't like you to read their
error messages.

You could also hack all the programs to use a user-specific logfile. Happy
hacking.

>    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.

>    - 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 ...

>    - start X sessions on the local machine
> 
> X doesn't really differentiate between local and remove machines from
> what I know.  So a remote X session is essentially the same as a local
> one.

It's the same as with the sound:
You may be annoyed if another one starts an X server on your machine ...

>    The current console user(s) should have almost root rights
>    (regarding hardware access, so not installing software),
> 
> Why give the user root access at all? Just make a new group and user,
> call them mixer for the mixer example.  And then make the owner of
> /dev/mixer mixer, and the group mixer.  Then just plunk in all users
> that want to change the volume into the group mixer.

In the case I agree with your argumentation above - I don't.

> Or just allow everyone to read/write to /dev/mixer, which is obviously
> the right thing todo.

See my explanations above.
 
>    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 ...).
> 
> Why not? I think it makes perfect sense.  Say I have a "audio system",
> that plays songs.  I connect to it remotely; shouldn't I be able to
> change the volume there?  Should I be _forced_ to go to the console to
> change the volume?

If you're the only user on that system, it's of course OK.
But would you like any other one with an account on the machine to do so?

> Saying what a user should be allowed to or not based on from where he
> or she is login in from is anti-social.

Let's provide root access to any user, then we'll get rid of any problems
like that. ;-)

>    1. the tty driver has to provide information which tty is currently
>       used
> 
> I think that this is already possible by just checking utmp or
> some such.

Not a really clean hack.
But I a possibility.

>    2. the file permission management has to be improved (it has to be
>    improved anyway).
> 
> Why?  And what is wrong with just providing ACL support?

Sorry, I don't know so much about ACL.
But an M$ troll (...) once said there were some problems with ACL with stuff
like renaming files.
Do you think he was right?

>    In the ideal case, it should be impossible for a console user to do
>    things that require console access over network.
> 
> Why?  And how do you decide what needs "console intervention" and what
> doesn't?  Isn't the point of GNU/Hurd to allow users to do whatever
> they might wish to do without screwing up for others?

Changing the volume might - even it's not the best/worst example.

> 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)

Sören

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