Re: X and other visions

[Alfred M. Szmidt]

   AFAIK GNU/Hurd will mainly support GGI/KGI instead.

Didn't know that you have a crystal ball that can look into the
future... :)

   (doesn't mean it won't support XFree86 any further, but I don't
   know ...)

X11 must be supported as long as X11 programs are used and as long as
the GNU desktop, GNOME, uses X11.

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

Wrong, check [hurd]/libdiskfs/console.c:diskfs_console_stdio().

But better error reporting by translators would be nice...

   I don't doubt you prefer logs instead of pop-up windows.

I never spoke about log files, I spoke of log-monitors.  They can
pop-up windows when a specific event happens.

   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.

Wrong, just fix syslogd (and/or syslog()) so that it can write to a
specific user-file.  All sane programs use this to report log
messages.  Then the log-monitor can watch that user-file.


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

That you don't think it is nice, is quite irrelevant.  What others
think is the important bit.  Allowing rebooting for users is quite
easy, just make a special sudo line or something for users that need
to reboot the system (let them only run /sbin/reboot for example).

That this happens over a network, or not is also irrelevant since
there is really no difference between those two.

   You play songs on computers of other people? May be a nice surprise
   ...

Yes, Paxillus, the music box, is not my computer.  You send a song to
it, it puts it on a stack, and pops it when the song is to be played.
You can also log in on a port and set the volume remotely.

   You may be annoyed if another one starts an X server on your
   machine ...

Why should I be first of all? And how is this different from starting
a ssh daemon running as a normal user on port >1024?  Or any kind of
daemon, which would include a X server into that set.  Are you going
to tell people what they are allowed to run and what they are not
allowed to run?

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

Yes.  And if I do not wish them to be able to do that, I can use
normal permission logic to disallow it.  No need to implement
stupidity for it.

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

Every user can become root, they can use a sub-hurd or even a
emulator.

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

Huh? It is the "tty driver" that is providing this information; just
what you wanted.  And infact, you can do it simpler, /dev/tty is
always the currently controled tty by a interactive processes.

In your shell you can type: tty, to see which tty is being used.

   But an M$ troll (...) once said there were some problems with ACL
   with stuff like renaming files.  Do you think he was right?

First, please do not call people names.  Name calling does not belong
in technical discussions.  Secondly, I cannot answer this question
since you have not told me what kind of problems the user had.

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

This doesn't answer any of the questions.

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

You didn't answer the question.

And that only root should be able to set a translator on a device node
that happens to be a real hard disk, is utterly stupid.  It goes
against ever sense of logic out there, if someone owns a node, then
that person should be allowed to do whatever they please to it,
_PERIOD_.