Re: X and other visions

[Sören Schulze]

Alfred M. Szmidt wrote:
>    AFAIK GNU/Hurd will mainly support GGI/KGI instead.
> 
> Didn't know that you have a crystal ball that can look into the
> future... :)

May I quote you?
You said once software wasn't something magic. ;)
Software is made by human decisions, and what I told you was also told me by
human persons.

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

XFree86 != X11

Have a look at XGGI.

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

OK, opening windows is not the problem.
But you have to know where you can reach the user with them.
See below.

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

OK, happy hacking and recompiling.
But I doubt end-user-space programs use syslog().
 
> 
>    >    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.

See above.

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

But wouldn't you also be able to change the volume when another one is
playing a song?
Would that be nice?

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

That's usually an admin's task.
What I'm talking about are only features, that may be disabled.

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

You are the owner of /dev/dsp?

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

Wonderful.
Being root may be a pleasure, but getting permissions on the parent machine
may be even better.

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

Oh, nice.
Unfortunately the XFree86 hack is too bad too support it.
But it fits very well in my ideas.

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

He is a troll because he only tells destructive stuff in a "Linux" forum.
But what he said is like this:
"When you do basic file operations [I think he meant mv in this case], the
ACL information of this files may be lost."

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

OK, let me finish the sentence:
Changing the volume might be a kind of screwing up.
And it's the admin's decision how to set permissions.

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

I think I did.
IMHO any user should be allowed to set a translator on a file according to
the permissions.
But finally it's the admin's decision.

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

I don't know what kind of data you store on your HD, but in some cases, it
may be bad anybody is allowed to set translators to any not-mounted
partitions.

Sören

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