bug-hurd
[Top][All Lists]
Advanced

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

Re: X and other visions


From: Alfred M. Szmidt
Subject: Re: X and other visions
Date: Sun, 13 Jun 2004 15:45:15 +0200

   GNU/Hurd is quite an unfinished system,

The only finished systems are the ones that are dead.

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

   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?

   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.

   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.

   - access the sound card and the mixer

Ditto.  I infact use the mixer and play songs remotely each and
everyday.

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

   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.

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

   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?

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

   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.

   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?

   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?


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?



Cheerio.




reply via email to

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