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 _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd
