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