Re: [9fans] 'wall' messages

Re: [9fans] 'wall' messages

[YAMANASHI Takeshi]

> plumb/seemail could be a solution though.

plumbing might have to face the namespace boundary too.

how about making news(1) to continue running and pops up
when news arrives in /lib/news?
--

Re: [9fans] 'wall' messages

[boyd]

nope

Re: [9fans] 'wall' messages

[Geoff Collyer]

write, postwrite and wall are clearly just a first cut, analogous to
write and wall on Unix.

As to the cited problems:

a) I added ORCLOSE and the /srv file went away much too soon, perhaps
on the first close rather than the last one.  I've had trouble with
this before and haven't sorted it out.

b) Right, a file server could provide reliable identification of
users.  I played a little with Dan's writefs last night and fixed a
bug or two.  Since then, it's been okay.

Re: [9fans] 'wall' messages

[rog]

> Okay, here are implementations of write and wall in under 100 lines.

couple of potential problems:

a) the pipes don't go away when you log out; maybe ORCLOSE would be a
good flag to add to the create.

b) anyone can pretend to be anyone else, or deny access to anyone else.

i'd think that b) could be solved quite simply by doing a little 9p
server and using authentication, but auth(2) doesn't seem to explain
server-side authentication overly much (auth_rpc gets a mention, but
that's all), and...  /sys/src/cmd/fossil/9auth.c (the only 9p code i
could think of that does auth) seems a little more complicated than i
was after.  maybe i've missed something and perhaps lib9p can handle
authentication automatically? (might be nice)

PS. nemo: http://www.vitanuova.com/test/termrc.gif
only 368 words though.

Re: [9fans] 'wall' messages

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 196 bytes --]

Now that file servers (fossil) just run on cpu servers, it does.  You just
have to import the service from the file server.  The file server will have
to offer it via exportfs but that's no big.

[-- Attachment #2: Type: message/rfc822, Size: 2196 bytes --]

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 'wall' messages
Date: Thu, 9 Oct 2003 16:07:12 +0100
Message-ID: <fe327a92812882a22bbda1235ca44fe3@vitanuova.com>

> I'm with rog.  All we need is a broadcast service in /srv.  Anyone
> writes into it and everyone reading it sees it.  It's basicly
> consolefs without the device.  Call it a chat room if you like.

problem is, that doesn't address the problem of fileservers going
away.  but i guess fileservers should be much more stable than cpu
servers (less chance of someone like me killing it with a dodgy job),
and perhaps a warning mail message is more appropriate in this case.

Re: [9fans] 'wall' messages

[rog]

> I'm with rog.  All we need is a broadcast service in /srv.  Anyone
> writes into it and everyone reading it sees it.  It's basicly
> consolefs without the device.  Call it a chat room if you like.

problem is, that doesn't address the problem of fileservers going
away.  but i guess fileservers should be much more stable than cpu
servers (less chance of someone like me killing it with a dodgy job),
and perhaps a warning mail message is more appropriate in this case.

Re: [9fans] 'wall' messages

[Bruce Ellis]

Geoff, you spoil all the fun.  I was waiting for screeds and
screeds of kernel code that scrummages around in everyones
namespace looking for places to write, and trying real hard
to only write to each place once.  And of course causing a
horrible mess to every window running anything but just rc.

Anyhow your code is shorter than Jim's speculations.

brucee
----- Original Message -----
From: "Geoff Collyer" <geoff@collyer.net>
To: <9fans@cse.psu.edu>
Sent: Thursday, October 09, 2003 10:31 AM
Subject: Re: [9fans] 'wall' messages


> Okay, here are implementations of write and wall in under 100 lines.
> I haven't used this code heavily but it worked when I last did.  You
> run `postwrite' in its own cpu-server window, which makes you
> reachable via write or wall by others on that cpu server.

etc

Re: [9fans] 'wall' messages

[Geoff Collyer]

Okay, here are implementations of write and wall in under 100 lines.
I haven't used this code heavily but it worked when I last did.  You
run `postwrite' in its own cpu-server window, which makes you
reachable via write or wall by others on that cpu server.


# To unbundle, run this file
echo postwrite.c
sed 's/^X//' >postwrite.c <<'!'
X/*
X * postwrite - post a pipe that others can write to;
X *	copy its contents to stdout.
X *
X * a file server version of this could tell who the writers are.
X * it might also be good to pop up a separate small window for each message.
X */

X#include <u.h>
X#include <libc.h>

enum { Rd, Wr };

int
mknmpipe(char *srvname)
X{
X	int fd, p[2];

X	if (pipe(p) < 0)
X		sysfatal("can't create pipe: %r");
X	fd = create(srvname, OWRITE, 0666);
X	if (fd < 0)
X		sysfatal("can't create %s: %r", srvname);
X	fprint(fd, "%d", p[Rd]);
X	close(fd);
X	close(p[Rd]);
X	// fprint(p[Wr], "hello");
X	return p[Wr];
X}

void
main(int argc, char *argv[])
X{
X	int n, pipe, errflg = 0;
X	char srvname[64], buf[256];

X	ARGBEGIN {
X	default:
X		errflg++;
X		break;
X	} ARGEND

X	if (argc != 0 || errflg)
X		sysfatal("usage: %s", argv0);

X	snprint(srvname, sizeof srvname, "/srv/to.%s", getuser());
X	if (access(srvname, 0) >= 0)
X		sysfatal("pipe %s already posted", srvname);
X	pipe = mknmpipe(srvname);
X	while ((n = read(pipe, buf, sizeof buf)) > 0)
X		if (write(1, buf, n) != n)
X			sysfatal("error writing stdout: %r");
X	remove(srvname);
X	if (n < 0)
X		sysfatal("error reading %s: %r", srvname);
X	exits(0);
X}
!
echo wall
sed 's/^X//' >wall <<'!'
X#!/bin/rc
X# wall word... - write words to all registered users
for (f in /srv/to.*) {
X	b=`{basename $f | sed 's/^to\.//'}
X	echo -n $b...
X	write $b $* &		# don't wait; pipe could be clogged
X	sleep 1
X}
!
echo write.c
sed 's/^X//' >write.c <<'!'
X/*
X * write - write a line to a user with his notification pipe in /srv
X */

X#include <u.h>
X#include <libc.h>

void
main(int argc, char *argv[])
X{
X	int i, pipe, errflg = 0;
X	char *user;
X	char srvname[64];

X	ARGBEGIN {
X	default:
X		errflg++;
X		break;
X	} ARGEND

X	if (argc < 2 || errflg)
X		sysfatal("usage: %s user word...", argv0);

X	user = argv[0];
X	snprint(srvname, sizeof srvname, "/srv/to.%s", user);
X	pipe = open(srvname, OWRITE);	/* and NOT create, which would fail */
X	if (pipe < 0)
X		sysfatal("%s: no pipe posted for user %s", srvname, user);
X	fprint(pipe, "%s %.5s: ", getuser(), ctime(time(0))+11);
X	for (i = 1; i < argc; i++)
X		if (fprint(pipe, "%s%c", argv[i], (i == argc-1? '\n': ' ')) < 0)
X			sysfatal("error writing %s: %r", srvname);
X	exits(0);
X}
!

Re: [9fans] 'wall' messages

[Jim Choate]

On Wed, 8 Oct 2003, Charles Forsyth wrote:

> you might think to notify people that the cpu server is going down
> by having it access devices imported from the terminal, but
> don't forget that the file server has no such access, and in many
> ways it's far more serious to have the file server go away.
> most reasonable solutions to the latter will deal with the former,
> including some of those suggested so far.

I have to agree with this. The main reason that I find this sort of
fail-over critical is if a process does die, if the file server is still
around we have some hope of restarting the job on another set of cpu
servers without the user even being aware, other than longer execution
times. If the file server dies the namespace is gone so we've no way to
ensure the intended namespace, we may not be able to build it up again
without user intervention. I find this most critical within the context of
what I call 'free run' agents. I envision a point when there will be
enough 'public' servers available that processes will be able to run
forever (for all intents and purposes), this is most important for example
with anonymous remailers, black nets/data havens, etc. In addition it
would allow the creation of 'public' search engines that simply were not
censorable because they weren't running in any particular place [1].

This of course means there needs to be a mechanism to track restarts and
alert the user if they're having too many.

[1] My personal belief is that this will be how the first self-aware AI
    comes about, a pure accident due to programs interacting and trying
    to survive. We'll get up one morning and all the phones will be
    ringing ;)

 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] 'wall' messages

[Charles Forsyth]

you might think to notify people that the cpu server is going down
by having it access devices imported from the terminal, but
don't forget that the file server has no such access, and in many
ways it's far more serious to have the file server go away.
most reasonable solutions to the latter will deal with the former,
including some of those suggested so far.

Re: [9fans] 'wall' messages

[mirtchov]

> I'm with rog.  All we need is a broadcast service in /srv.  Anyone
> writes into it and everyone reading it sees it.  It's basicly
> consolefs without the device.  Call it a chat room if you like.

i've written a prototype, basically modifying consolefs to use an
'empty' device and adding some niceties to show who's talking.

i'll rewrite into a full-fledged file server serving 'rooms' probably
by the end of next week.  and will send it here for everybody to use.

it's possible that i'll serve a file descriptor somewhere on
ucalgary.ca for everybody who cares to mount and have a chat without
having to worry about irc clients for plan9 (and restricting it to
plan9 users only :), using their sources.cs usernames

andrey

Re: [9fans] 'wall' messages

[David Presotto]

I'm with rog.  All we need is a broadcast service in /srv.  Anyone
writes into it and everyone reading it sees it.  It's basicly
consolefs without the device.  Call it a chat room if you like.

Re: [9fans] 'wall' messages

[a]

// The final observation about drawterm is that it's one way...

again, i must disagree. cd /mnt/term and have a look around. want
your local file system? there it is. your /dev is even sorta in
there, as well as a "constructed" Plan9-style /dev.

the reason this isn't a problem is because, by default, my
connections to other machines are not automatically reciprocal.
glenda has no access to those files, buecause i've not done
anything to present my resources into a namespace glenda can
get at. now if i export /mnt/term into /srv/ScrewWithMe, all
bets are off.
ア

Re: [9fans] 'wall' messages

[a]

// there should be -no- additional programming or commands for a user
// to do this.

on the part of the user, i assume you mean. otherwise it seem you'd
have to hope for it to magically apear. so you must be okay with some
programming on the part of , well, programmers, although it's
clearly desirable to minimize that, as well. kernel hacking is time
consuming and more dificult (at least to test and debug, if not to
write) than user-level code. so it seems like that'd be preferable,
if we can get what we want there. we'll see that we can in a minute.

// it needs to be available to all users, with the owner of the box
// where the hardware is resident being in control of the security.

the problem here is that there's more then one box involved, with
more than one owner. using the example at hand, if i cpu in to a
remote server, most (much?) of /dev is owned by me, parts by glenda
(and, ahem, none by bootes). so what gives the owner of the cpu
server the "right" to write to my devices? clearly, i need to be
able to allow the cpu server to, but that's *my* control. so i (or,
more likely, something acting on my behalf) needs to present to the
cpu server a way to get notices to me. default behavour should
always err on the side of too little sharing by default.

// since there are at least two filesystems that a cpu server can
// run native (ie kfs and fossil) it needs to be outside of those;
// ...That leaves only -one- place, the kernel.

falacy of false alternatives. "It can't be A so it must be B". The
correct initial response to such statements is almost *always*
"What about C?" (no pun intended). we've still not explained why
this can't be done in user mode ("i've seen it done!"). i come back
to the example of the plumber. the user does nothing to start it,
the user maintains controll of all the relevant resources, and
applications on multiple platforms communicate without knowing
anything about each other - just the plumber interface.

you seem to be under the impresion (especailly in your last
paragraph) that people are arguing that we shouldn't be allowed
to share resources. that's not at all what people are saying. we
just don't think kernel hacks to allow a privlidged user to get
access to a users's namespace - globally, generally - is any sort
of good idea.
ア

Re: [9fans] 'wall' messages

[rt]

// ...rc hands off to rio so there is zero problem here.

you're missing the point again. right now, the "handing off"
process is really simple. what you're suggesting would
require rc to be able to communicate with rio in some other
channel of communication. you'd have to define the interface
and implement it. thus adding complxity to both programs.
it also seems like a pre-requisite would be getting some
sort of hook between the OS and apps (the thing rc would be
"handing off" presumably).
ア

Re: [9fans] 'wall' messages

[Jim Choate]

On Wed, 8 Oct 2003 rt@9srv.net wrote:

> // After all rio runs from a rc prompt.
>
> the process, of course, might not be around. see exec in rc(1).

True enough, but rc hands off to rio so there is zero problem here.

 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] 'wall' messages

[rt]

i confess i don't remember whhat jmk's proposal was. however...

note brucee said "knowing about" not "running". using the plumber
(or something like the one-off system-message-notifier we did for
Inferno) the OS doesn't have to possess any special knowledge of
*anything* to enable this. in everything you've described, the
shell, the OS, rio, other apps, or some combination thereof have
to have special-purpose logic built in, and would likely require
some knowledge of each other (you'd need to build the "registration
service" or whatever).

the point of things like not including a terminal driver in the
windowing system, or not putting an editor in the shell, wasn't as
much about putting complexity "in the right place" (i believe) as
not having it there at all. to quote one of the brightest things
boyd ever said (here, at least):
 missing components don't make mistakes, are secure, and
 don't need testing, documentation, or maintenance.
paraphrasing Gordon Bell, who said it even better:
 The cheapest, fastest, and most reliable components are those
 that arn't there.

we can do a "wall" without kernel hacks, without touching any
existing apps, and with a minimum of new code.
ア

Re: [9fans] 'wall' messages

[rt]

// After all rio runs from a rc prompt.

the process, of course, might not be around. see exec in rc(1).

// So track the initial connection and...

*who* tracks the initial connectin? you're adding complexity here,
either directly to rc (which is likely unproductive for the above
reason, among others) or to the OS (some sort of "reporting
mechanism", most likely).

// ...not being a /dev, that's a simple issue of creating a logical
// alias on that initial rc connection into /dev/display/*.

uh, what? i'm going to have something *pretend* to be a graphics
device, just for the purposes of system notices? and how does it
tell other gui apps (or how do they all figure out) that it's not
a *real* graphics device? again, added complexity. part of the
"everything is a file, and *just* a file" model, with plan 9's
namespace system, means that the only way these apps know what's
what is convention. apps *assume* /dev/draw is a graphics device.
you could put your net or audio device there without issue, but
thigs are gonna get fsck'd up.

what hoops are you worried about users jumping through? we (or
the guys at the labs) make a change to /sys/lib/newuser to start
some listener, or /rc/lib/rcmain sources some system-wide
startup, containing reasonable defaults. plumber starts every
time i log in, my apps know how to talk to it, and i get all
these "magical" benifits of things working nicely together, all
without any hoop-jumping.

i have no idea what you're concerned about here.

Re: [9fans] 'wall' messages

[rog]

> Exactly! So if a write to the structures on the cpu would work locally they
> will work with drawterm, since the processes are running on the cpu server
> side and that is the box that wants to send the shutdown warning. The fact
> that I'm accessing those resources via drawterm is really moot.

you're assuming, i believe, that connections to the cpu server are
uniform: i.e.  that each connection to the cpu server imports a
namespace from the remote side that contains a draw device, etc.

in fact that's not necessarily the case: if i distrust the cpu server,
i might export to it a namespace containing only my /dev/cons.
in fact, if i telnet to the cpu server, there's no namespace
(and who's to say that i'm not running some odd protocol
over the telnet link?)

to get back to the original request (how do we inform all users that
the machine is going down?): while mail is an option, it doesn't
necessarily work well, particularly if there are many cpu servers,
going up and down frequently: users would be likely to get many
irrelevant messages.

surely all one needs is a per-machine service that provides such
information to whoever asks for it?  something simple in /srv should
do the job.  that way, users can choose to display the info however
their GUI preferences might indicate; moreover, the information is
potentially available to non-interactive programs that might wish to
take evasive action in the fact in imminent shutdown.

  rog.

PS. of course, "wall" in unix-like systems doesn't necessarily help
much in these GUI-oriented days: who's to say a user is displaying the
output from any ptys?

Re: [9fans] 'wall' messages

[Dan Cross]

Ralph Corderoy <ralph@inputplus.co.uk> writes:
>
> > look jim, don't go 'head to head' with brucee.
>
> Butt out, boyd.
>
> Go-orrn, brucee.  'it 'im.

You know, as much as you complain about it, you should take your own
advice about zero-content posts.  In particular, you might have noticed
that boyd unsubscribed, so you're just talking to thin air.

	- Dan C.

Re: [9fans] 'wall' messages

[Jim Choate]

On Wed, 8 Oct 2003, Douglas A. Gwyn wrote:

> Sheesh.  People are things too.

Oh god...

> > This is one advantage, security through obscurity, ...
>
> That is an abuse of the term "security through obscurity",
> originally introduced only as a label for a failed idea,
> not as a recommendation.

No it's not. It injects a level of complexity or resource usage that makes
the cost of doing the job higher. The intent of that is to lock out those
who don't have the entry level resources.

It's an -exactly- fair use of the term.

 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] 'wall' messages

[Jim Choate]

On Wed, 8 Oct 2003, Ralph Corderoy wrote:

> > The bottom line is that my view is that the complexity should be in
> > the OS hidden from the users
>
> but it could be that they feel it's better to not have the facility
> until a non-complex method can be conceived rather than add complexity
> anywhere, including the OS.

I understand that point, clearly. I want it to be as simple as possible
with a couple of provisos,

* there should be -no- additional programming or commands for a user to
  do this. The basic skeleton is already there in the namespace and that
  is where it needs to stay. Not in some command line solution. That's
  an ugly kludge at best. In other words it must be consistent with the
  current cat/cp sort of approach, if another approach is taken the this
  add another layer of commands and that complicates things. People
  expect to be able to cat/cp to anything in a namespace, and that
  includes hardare. It's all a filesystem after all, and any other
  approach will break that paradigm and add confusion.

* it needs to be available to all users, with the owner of the box where
  the hardware is resident being in control of the security.

* it needs to work across -all- hardware devices such as displays,
  keyboards, mice, soundcards, etc. It is critical that P9 make it as
  easy as possible to share these resources, as well as deny the
  sharing. Standard file permissions look like the cats meow to me.

* the owner of the box is the one who decides the range of these services
  and nobody else.

* since there are at least two filesystems that a cpu server can run
  native (ie kfs and fossil) it needs to be outside of those; otherwise
  you've got to write the code twice - yuck. That leaves only -one-
  place, the kernel. This implies two points worth delineating; 1.
  devices need to be 'logged' at boot. 2. each new user connection that
  generates a std out/std err needs to be included. 3. it can't make any
  different to the command syntax or the recipient of such messages what
  their interface is.

I see this functionality as critical to the real world success of P9. For
example with this VoIP becomes easy; I cat my microphone to your sound
card and visa versa. Musicians sharing a set of MIDI channels from several
seperate locations becomes easy. It would have a big impact in training &
education with regard to being able to grab students displays one at a
time, as well as being able to dump content to them all at once. Robotics with
respect to agent clouds becomes a lot simpler than anything that's out
there now. MMOG's would recieve a massive boost from this sort of sharing
with regard to having the actual engine running in a processor cloud. This
helps solve the 'shared world synchronicity' problem in a big way (for
examples ping times become something the game can use directly to level
the playing field). Couple this with things like global sign-on and you
really start to see the power.


 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] 'wall' messages

[Ralph Corderoy]

> look jim, don't go 'head to head' with brucee.

Butt out, boyd.

Go-orrn, brucee.  'it 'im.

Re: [9fans] 'wall' messages

[Ralph Corderoy]

Hi Jim,

> It's not like there is any magic there, it's bits, it -all- breaks
> down to read/write/and/or/not/shift/jump on bits in ram or a register
> in the final analysis.

I don't think anyone here is disagreeing that technical solutions can't
be implemented -- it's just a simple matter of programming...

> The bottom line is that my view is that the complexity should be in
> the OS hidden from the users

but it could be that they feel it's better to not have the facility
until a non-complex method can be conceived rather than add complexity
anywhere, including the OS.

Cheers,

--
Ralph Corderoy.      http://inputplus.co.uk/ralph/     http://troff.org/

Re: [9fans] 'wall' messages

[Douglas A. Gwyn]

Jim Choate wrote:
> Users can't trust the OS, they can only trust the group running it, or
> not. A fundamental and basic security flaw that has let more than one
> hacker into a system. And will continue to do so until people get burned
> enough to realize that 'trust' -only- applies to people, never things. ...

Sheesh.  People are things too.

> This is one advantage, security through obscurity, ...

That is an abuse of the term "security through obscurity",
originally introduced only as a label for a failed idea,
not as a recommendation.

Re: [9fans] 'wall' messages

[Jim Choate]

On Wed, 8 Oct 2003, Bruce Ellis wrote:

>  drawterm sets up and maintains a namespace
> which is exported to the cpu server just as a p9 terminal does.

Exactly! So if a write to the structures on the cpu would work locally they
will work with drawterm, since the processes are running on the cpu server
side and that is the box that wants to send the shutdown warning. The fact
that I'm accessing those resources via drawterm is really moot.

With reference to the box the drawterm itself is running on, that's a
function of that OS and isn't an issue with drawterm or the cpu server.
When that box goes down drawterm will be killed in some manner and as a
result the connection to the cpu server is closed and those resources are
released and there isn't anything else to send a message to about the cpu
shutdown (assuming there aren't other users on of course) because that
resource pool has already been released.

And I challenge the 'just as a P9 terminal does', I am assuming by
'terminal' you mean I/O server. The difference is that the I/O server can
run processes locally whereas drawterm can't. So there is clearly a
difference in the way namespaces can interact, and the limits on which
the two approaches can interact with that data stream. One example is that
a I/O server could export its local kfs to a process on that cpu server, but
drawterm can't export its local filesystem. Near as I can tell if you want
that you need to use native tools to export that to the cpu server and
then you can import it into a namespace.

The final observation about drawterm is that it's one way, a user can use
drawterm on a box to modify the cpu server but the cpu server can't modify
the drawterm host outside of the drawterm resources. If you could run a
process on the cpu server and use that to 'tunnel' through drawterm and,
for example, reset the drawterm host that would clearly be a bug in
drawterm.


 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] 'wall' messages

[Jim Choate]

On Tue, 7 Oct 2003, Joel Salomon wrote:

> VNC might have been a better example - it doesn't appear to provide
> *anything* but the keyboard/mouse/screen

I'm not sure I follow your exact point here, so I'll respond to what I
think you mean...

But processes don't run on the VNC console so this example is actualy
moot. So if you could write to that display on that box the fact its
exported by VNC would not be an issue. If it did then VNC would be capable
of -modifying- the bit stream, not just creating a copy and sending it
elsewhere, and that should be a no no. It's on somebody elses hardware
and generaly trying to impose your views there is a Bad Thing (TM)
without their consent.

The rc and rio processes would still be running on the server, not the VNC
console. And that is where you want to write the wall to. The VNC will
pick it up as part of its normal operations.


 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] 'wall' messages

[Jim Choate]

On Wed, 8 Oct 2003, Bruce Ellis wrote:

> jmk's original solution achieves this without the operating system
> knowing about rio or any other program.

Really? What solution was that, plumbing? That is certainly another
program. If that were true this would be a non-issue and the original
question would have been some simple command line that had a message
string and some sort of target list (where all users would be a wild card
like *). It is certainly possible to only want to send messages to classes
or groups of users so using a regex needs to be available in the solution
s well.

If it runs it's a program, if it doesn't run its data. Period. There is
zero gray area. If the user has to do anything other than provide the name
of the program, the message, and some identifier for the target group it's
too complicated.

 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] 'wall' messages

[Bruce Ellis]

jmk's original solution achieves this without the operating system
knowing about rio or any other program.

> users shouldn't have to jump through hoops to do things as simple as
> sending a note to all logged in users.

Re: [9fans] 'wall' messages

[Jim Choate]

On Tue, 7 Oct 2003 a@9srv.net wrote:

> another problem with the 'echo 'rebooting now' > /dev/screen/*' or
> whatever is the fact that it requires more specific resources to
> exist. my primary interaction with plan 9 these days is (sadly) via
> ssh (ether on Virtual PC, anyone?), so most of the common /dev
> entries present on a terminal, via drawterm, or via vnc won't show
> up for me.

I don't see that as a serious problem. After all rio runs from a rc
prompt. Looks to me like all connections start with a rc shell that then
invokes other programs in some manner. So track the initial connection and
then as other things get cranked up (eg rio) you simply follow the chain.
The OS has to have a means (probably vector tables of one sort or another)
to keep track of it.

And as to there not being a /dev, that's a simple issue of creating a
logical alias on that initial rc connection into /dev/display/*. As that
gets updated (ie I execute the 'rio' command) another logical device could
be added or even replace the rc connection. In the case of a serial device
the logical link would work the same way once the handshaking was
completed.

It's not like there is any magic there, it's bits, it -all- breaks down
to read/write/and/or/not/shift/jump on bits in ram or a register in the
final analysis. The bottom line is that my view is that the complexity
should be in the OS hidden from the users (including bootes/eve) and the
users shouldn't have to jump through hoops to do things as simple as
sending a note to all logged in users. The exact scope of that permission
(ie should it be bootes/eve or all users or just particular groups)
should be left up to the system operators and a config script of some
sort.

The ability to share resources -is just as important- as being able to
prevent access. Perhaps more so if you're speaking of individuals working
on groups.

 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] 'wall' messages

[okamoto]

> my bets are on brucee
Because Jim Choate pretends he knows that!
Of course, unfortunately, he doesn't.   If someone who wants
to be teached by someone, he should say, "May I ask you..."

Kenji

Re: [9fans] 'wall' messages

[a]

another problem with the 'echo 'rebooting now' > /dev/screen/*' or
whatever is the fact that it requires more specific resources to
exist. my primary interaction with plan 9 these days is (sadly) via
ssh (ether on Virtual PC, anyone?), so most of the common /dev
entries present on a terminal, via drawterm, or via vnc won't show
up for me.

i've used a system based around /chan in inferno (/chan is more or
less inferno's version of /srv), and been quite pleased. it's been
a few years, but we may have even had the same file visable in both
plan 9 and inferno. we had a little logger window that printed out
messages and un-minimized itself when one came in, or you could just
cat it if you're on a text console.

the point of doing it that way was it offered a ton of flexability
as far as the software that presented the message to the user (from
'cat' to our Limbo/Tk app). and whatever the software was, it was
really simple, and the user could choose where the notifications
went, how they were presented, &c.; not so with the schemes using
direct manipulation of things in /dev.

i suspect the plumber could be used to great effect here. that's
another amazing bit of kit.

i've also played around with system-wide "profiles", executed via
/rc/lib/rcmain, before the $home/lib/profile, but wasn't sure what
i though of that. it's useful, to be sure, but another thing to
maintan and another thing going on more-or-less without the users
knowledge. which isn't always a bad thing, but...

this is all in addition to the security/architecture complaints
\x05people have pointed out so far, which i think are dead on.
ア

Re: [9fans] 'wall' messages

[boyd]

look jim, don't go 'head to head' with brucee.

Re: [9fans] 'wall' messages

[Joel Salomon]

>>Really? And where is that when I'm running Drawterm for example?
>
> where do you think?  drawterm sets up and maintains a namespace
> which is exported to the cpu server just as a p9 terminal does.
>
from drawterm(8):
> drawterm serves its local name space as well as some devices (the
> keyboard, mouse, and screen) to a remote CPU server

Seems to me that this is a *minimal* namespace - /dev/draw, mouse, and
cons; as well as some serving of the local (windows or *n?x) file system.

VNC might have been a better example - it doesn't appear to provide
*anything* but the keyboard/mouse/screen

--Joel

Re: [9fans] 'wall' messages

[Bruce Ellis]

>> absolute horseshit.  i guess you don't understand that the namepace
>> of the user is in their terminal p9, not on the cpu server.  as for your
>> claims about user priv, well you don't understand auth either.
>
>Really? And where is that when I'm running Drawterm for example?

where do you think?  drawterm sets up and maintains a namespace
which is exported to the cpu server just as a p9 terminal does.

Re: [9fans] 'wall' messages

[Ralph Corderoy]

Hi Dan,

> You know, I'd like to see a picture of Choate.

Which one of you is Roadrunner, that's what I want to know.

Cheers,

--
Ralph Corderoy.      http://inputplus.co.uk/ralph/     http://troff.org/

Re: [9fans] 'wall' messages

[Dan Cross]

mirtchov@cpsc.ucalgary.ca writes:
> go back to dumbing down documentation down "texas style".  obviously
> that's the only contribution you can make to Plan 9.  (please, though,
> let some of your people who speak english do it; someone who knows
> that "you're" != "your").

Actually, I kind of wish he wouldn't do it; incorrect information
is even worse than no information, and his information doesn't stand
a very good chance of being correct.  You know, I'd like to see a
picture of Choate.  Put a face to the (infamous) name.

	- Dan C.

Re: [9fans] 'wall' messages

[mirtchov]

> Ok chuckles, news flash.
>
> I'm -not- North Korea.

uninteligent.  guess you couldn't see what i was telling you, so you
decided it isn't there.

go back to dumbing down documentation down "texas style".  obviously
that's the only contribution you can make to Plan 9.  (please, though,
let some of your people who speak english do it; someone who knows
that "you're" != "your").

Re: [9fans] 'wall' messages

[Dan Cross]

Lucio De Re <lucio@proxima.alt.za> writes:
> Specially with recalcitrant learners.

There's a difference between recalcitrant learners and ignorant
megalomaniacs pushing agendas.  I'm all for the former, but trying to
win over the latter is a waste of time.  It's like trying to have a
rational discussion with theo deraddt.

I'm sorry, but after *two years* of Choate and his antics, I'm just not
willing to give the guy the benefit of the doubt anymore.  The
ignorance, arrogance, posturing, and every post ended by a one-line
insult to either someone's intelligence or `tone' is just counter
productive.  He's been around here a long time, and his posts still
indicate he doesn't really know what's going on, but it's for want of
listening, not lack of people trying to help him.  I'm sorry, but I'm
not going to waste my time on someone who can't find anything better to
do than insult me in return for the time I devote to patiently trying
to discuss things with him.  Hell, the guy can't even figure out that
cat and cp do roughly the same thing.

I've even started filtering him out, but I still read his drivel in
what other's quote.  Oh well.

	- Dan C.

Re: [9fans] 'wall' messages

[Jim Choate]

On Mon, 6 Oct 2003, andrey mirtchovski wrote:

> On Mon, 6 Oct 2003, Jim Choate wrote:
>
> > I challenge you to specifically detail why this is being a dictator.
> >
>
> plus:
>
> > bootes should be able to alias into any users namespace on that box.
>
> one word: "1984"

I'm still waiting. As to 1984, why read a copy, go to the original source.
Zamyatin's "We". 1984 and Brave New World are shallow clones. Typical of
the 'western' approach. You can find copies at your local bookstore (both
new and used).

At least Zamyatkin can say he lived it by putting his own life on the
line with that book.

> ok, real life example -- North Korea, ca 1988, the hotel in Pyongyang where

Ok chuckles, news flash.

I'm -not- North Korea.

You're blowing smoke. It's called a 'strawman'.


 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] 'wall' messages

[Jim Choate]

On Tue, 7 Oct 2003, Bruce Ellis wrote:

> absolute horseshit.  i guess you don't understand that the namepace
> of the user is in their terminal p9, not on the cpu server.  as for your
> claims about user priv, well you don't understand auth either.

Really? And where is that when I'm running Drawterm for example?

And Where do programs run when they're not on the P9 terminal? Do those
processes ever need access to those namespaces and the resources made
available at that point?

As to understanding auth, I didn't write the documents. I'm not the one
who has never written a architecture document that is actually in date.

> oh and i found this on another mailing list.

Cypherpunks, a list I helped operate and define the parameters for. At
least until last week when I got tired of taking all the heat, two federal
cases in 5 years, five or six subpeonas, enough crap to make a mountain
of molehills.

> "The relentless mass spamming by professor rat and Jim Choate
> keeps new comers away, since 99% of the posts to the list is
> from people who hate the ideas that the list was created to
> further, and seek to shut it down, to prevent thought about and
> discussion of such ideas..."
>
> Now I know what you do when you don't sprout garbage here.

You really should have dug deeper, I run (well ran) one of the Cypherpunks
nodes. The 'mass spamming' is a long running conflict between the
democratic and CACL contingents on that list. It demonstrates a
fundamental hypocrisy in their approach. It's why they did -exactly- what
they're supposedly against, create 'statist havens' where they can control
other actions.

Why don't you explain -exactly- the context of that statement? It
shouldn't be hard, I've been on the Cypherpunks list nearly since day one
back in '92. There are lots of archives. Why not track it back and better
understand the dynamics that caused those comments to be made. And while
you're at it, explain what those dynamics.

I'll even give you a hint, free speech and users managing their own
mailbox instead of appealling to 'daddy' to take care of it.

You speak from utter ignorance of the Cypherpunks and the dynamics of that
group.

Apples and Oranges for no other reason than to satisfy your bruised ego.


 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] 'wall' messages

[Jim Choate]

On Tue, 7 Oct 2003, Lucio De Re wrote:

> On the other hand, a reply that explains that the namespace is
> sacred and inviolate, otherwise users cannot trust the operating
> system,

Users can't trust the OS, they can only trust the group running it, or
not. A fundamental and basic security flaw that has let more than one
hacker into a system. And will continue to do so until people get burned
enough to realize that 'trust' -only- applies to people, never things. And
even then it's mercurial (eg anybody ever had a girlfriend cheat on
them?).

This is one advantage, security through obscurity, where closed source
OS'es -are- more secure than Open Source. And yes, it is a thin edge, but
a edge never the less. The owners of the vast majority of boxes can't
de-compile the binaries and then modify them for what is  effectively a
MITM attack. Open Source OS'es don't have this, in fact it's a common
suggestion that people should in fact work on their own boxes (and many
do).

> that security in Plan 9 hinges on the absence of superior
> privilege (root user) which prevents malicious users from being
> able to hijack the CPU server, that "eve" and not "bootes" is

And bootes is absolutely prevented from aliasing as eve, ever? Even if
they're running on the same box at the same time? I think somebody is more
interested in cannon than reality.

Does bootes -ever- have a process that is running the cpu in supervisor
mode? A single NOP that can be replaced with a jump or branch? If bootes
(or eve for that matter) ever run the cpu in supervisor mode then they can
take control of the VMM on that machine and snapshot everything a user
does or has. So, unless you've got some sort of secure vault to run
in (eg WOM on DSS smart cards) your security with respect to the hardware
and basic OS are really a mirage.

> allowed to provide a trampoline for a user to access a file server,
> all these things make better archive material than tirades about
> lack of understanding.

And that's not written down clearly anywhere. One of the perennial
complaints I hear is that the documentation of Plan 9 sucks. And yes,
Hangar 18 is doing something about that.

I've read -every- damn P9 document that's out there on the site, they
suck. They're out of date, they're written in the wrong tone, etc., etc.,
etc.


 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] 'wall' messages

[matt]

>Someone here ought to get across to them, instruct them.  Not
>necessarily you or I, but by being critical we may be making it
>difficult for those who would otherwise be willing to try.

"willing to try" implies that they won't insult you when you answer their simple questions

m

Re: [9fans] 'wall' messages

[Lucio De Re]

On Tue, Oct 07, 2003 at 02:15:51PM +0100, matt@proweb.co.uk wrote:
>
> "willing to try" implies that they won't insult you when you answer their simple questions
>
I rather mangled what I wanted to say.  I meant that our being
critical would discourage those who would, in our stead, be prepared
to teach, would be less likely to get emotional or personal.

Specially with recalcitrant learners.

++L

Re: [9fans] 'wall' messages

[boyd]

my bets are on brucee

Re: [9fans] 'wall' messages

[Lucio De Re]

On Tue, Oct 07, 2003 at 09:27:54PM +1000, Bruce Ellis wrote:
>
> when i see stuff like this:
>
> >     echo "WARNING: REBOOT AT 21:00" > /dev/display/* >> /lib/news
>
> and
>
> >    You're position basically lets the user have free reign over something
> >    that isn't theirs. Yuck!
>
> i think that someone should be reading the manuals and ... i give up.

... which contributes to the impression that we're a bunch of inbred
fanatics on this list <grin>

My mentor (one of them, but the first I thought of as such) had a neat
little phrase: "Think of them as competition".  Here, a more
appropriate one may be "Think of them as the majority".

Someone here ought to get across to them, instruct them.  Not
necessarily you or I, but by being critical we may be making it
difficult for those who would otherwise be willing to try.

And even though I believe that "there is no such thing as good
example" I have no difficulty recognising a bad example when I see it.
And those are much, much easier to follow.

What I'm hoping is that we'll all learn from the recent inane
debacles to make the tone on this mailing list more instructive or, at
least, less destructive.

There's an amazing amount of learning I find in the topical postings
here and I'm not afraid to admit that almost all the regulars have
contributed in some manner to this learning, let's encourage that type
of message.

But Bruce, please don't take it personally, the only reason I chose your
posting was because it was the most recent example.  I'm sure I could
have found one of my own, had I looked for it.

++L

Re: [9fans] 'wall' messages

[Bruce Ellis]

perhaps a longer sentence may have been more instructive to me.

when i see stuff like this:

>     echo "WARNING: REBOOT AT 21:00" > /dev/display/* >> /lib/news

and

>    You're position basically lets the user have free reign over something
>    that isn't theirs. Yuck!

i think that someone should be reading the manuals and ... i give up.
----- Original Message -----
From: "Lucio De Re" <lucio@proxima.alt.za>
To: <9fans@cse.psu.edu>
Sent: Tuesday, October 07, 2003 8:41 PM
Subject: Re: [9fans] 'wall' messages


> On Tue, Oct 07, 2003 at 07:50:08PM +1000, Bruce Ellis wrote:
> >
> > absolute horseshit.  i guess you don't understand that the namepace
> > of the user is in their terminal p9, not on the cpu server.  as for your
> > claims about user priv, well you don't understand auth either.
> >
> On the other hand, a reply that explains that the namespace is
> sacred and inviolate, otherwise users cannot trust the operating
> system, that security in Plan 9 hinges on the absence of superior
> privilege (root user) which prevents malicious users from being
> able to hijack the CPU server, that "eve" and not "bootes" is
> allowed to provide a trampoline for a user to access a file server,
> all these things make better archive material than tirades about
> lack of understanding.
>
> Just my opinion, of course.
>
> Also, in passing, Jim Choate is not very active on the Lego Robotics
> mailing list, but I've found most of his comments there (I ought
> to shut up, oughtn't I?  Maybe I'll unsubscribe from there, now) to
> be a lot less inflammatory than here.  Mostly useful, only occasionally
> unhelpful.  Never really insulting.  For what it's worth...
>
> ++L
>

Re: [9fans] 'wall' messages

[Lucio De Re]

On Tue, Oct 07, 2003 at 07:50:08PM +1000, Bruce Ellis wrote:
>
> absolute horseshit.  i guess you don't understand that the namepace
> of the user is in their terminal p9, not on the cpu server.  as for your
> claims about user priv, well you don't understand auth either.
>
On the other hand, a reply that explains that the namespace is
sacred and inviolate, otherwise users cannot trust the operating
system, that security in Plan 9 hinges on the absence of superior
privilege (root user) which prevents malicious users from being
able to hijack the CPU server, that "eve" and not "bootes" is
allowed to provide a trampoline for a user to access a file server,
all these things make better archive material than tirades about
lack of understanding.

Just my opinion, of course.

Also, in passing, Jim Choate is not very active on the Lego Robotics
mailing list, but I've found most of his comments there (I ought
to shut up, oughtn't I?  Maybe I'll unsubscribe from there, now) to
be a lot less inflammatory than here.  Mostly useful, only occasionally
unhelpful.  Never really insulting.  For what it's worth...

++L

Re: [9fans] 'wall' messages

[Bruce Ellis]

absolute horseshit.  i guess you don't understand that the namepace
of the user is in their terminal p9, not on the cpu server.  as for your
claims about user priv, well you don't understand auth either.

oh and i found this on another mailing list.

"The relentless mass spamming by professor rat and Jim Choate
keeps new comers away, since 99% of the posts to the list is
from people who hate the ideas that the list was created to
further, and seek to shut it down, to prevent thought about and
discussion of such ideas..."

Now I know what you do when you don't sprout garbage here.

brucee
----- Original Message -----
From: "Jim Choate" <ravage@einstein.ssz.com>
To: <9fans@cse.psu.edu>
Sent: Tuesday, October 07, 2003 1:31 PM
Subject: Re: [9fans] 'wall' messages


> Wait a minute, the users don't own those resources, they're borrowing
> them. Within the context of the particular hardware it is completely
> reasonable to leave bootes in control. Nobody is suggesting that bootes
> necessarily be able to go out off that hardware and act as that user.
>
> You're position basically lets the user have free reign over something
> that isn't theirs. Yuck!

Re: [9fans] 'wall' messages

[andrey mirtchovski]

On Mon, 6 Oct 2003, Jim Choate wrote:

> I challenge you to specifically detail why this is being a dictator.
>

plus:

> bootes should be able to alias into any users namespace on that box.

one word: "1984"

ok, real life example -- North Korea, ca 1988, the hotel in Pyongyang where
all foreigners from the 'friendly' countries stay has all pictures on the
walls in every room _obviously_ bugged with miniature cameras.

but that's OT, now back to our previously scheduled program :)

Re: [9fans] 'wall' messages

[Jim Choate]

On Mon, 6 Oct 2003, andrey mirtchovski wrote:

> On Mon, 6 Oct 2003, Jim Choate wrote:
>
> > You're position basically lets the user have free reign over something
> > that isn't theirs. Yuck!
>
> how very, very wrong. if you want to be a dictator on your network you
> surely won't get many users (how many does H18 have, exactly?).

I'm not being a dictator at all. I'm simply ensuring that bootes who is
responsible for the integrity of the system (which if compromised effects
-all- users) can reach all users easily and in a -elegant- way (as in
simple, easy to follow). Having to invoke several other programs and jump
through hoops that can be accomplished by a simple extension is the wrong
approach. Complicating the users environment is -never- a -good- thing,

It's not supposed to be a IQ test, it's supposed to do the work for you.

> in the real world, users are exactly the ones who pay for the hardware
> you want to 'play god' on; sysadmins are only there to protect them from
> each other.

And the sys admin.

Bottom line, it should be simple and consistent. A wo access to local
resources for users is not unreasonable.

I challenge you to specifically detail why this is being a dictator.

Extreme claims require extreme evidence.

 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] 'wall' messages

[boyd]

it has nothing to do with the namespace.  bootes is a 'bit' special.

but, it can't write on, say, /usr/boyd/foo if it's 644,

a) try and hack into sdgm.net
b) tyy and create /usr/boyd/foo as bootes

ps. prizes from /dev/null

btw: if you hack into sdgm.net (which i doubt you can do) you'd be up
on a 'data crime' charge.  do you like gaol?

Re: [9fans] 'wall' messages

[Jim Choate]

On Mon, 6 Oct 2003, Dan Cross wrote:

> Yes.  That's just a reinvention of root; not a good idea.  We've spent

No it's not. It simply lets bootes have access to -his- local resources so
that he could do things like dump a message to all logged in users.

When the original pointers are setup to the resources, a link is made into
bootes namespace. It could even be one way, bootes to the device, it
wouldn't necessary for bootes to read the device. The same for sound and
other such.

So, no, it's not the same at all.

 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] 'wall' messages

[andrey mirtchovski]

On Mon, 6 Oct 2003, Jim Choate wrote:

> You're position basically lets the user have free reign over something
> that isn't theirs. Yuck!

how very, very wrong. if you want to be a dictator on your network you
surely won't get many users (how many does H18 have, exactly?).

in the real world, users are exactly the ones who pay for the hardware
you want to 'play god' on; sysadmins are only there to protect them from
each other.

recommended reading: scary.devil.monastery archives

Re: [9fans] 'wall' messages

[boyd]

    If someone wants Linux, they know where to find it.

texas?

Re: [9fans] 'wall' messages

[Dan Cross]

"Bruce Ellis" <brucee@chunder.com> writes:
> giving bootes some god-awful power to hijack other namespaces
> is not a very good solution.

Yes.  That's just a reinvention of root; not a good idea.  We've spent
many long years getting away from that.  Going back would be, well, a
step backwards.

If someone wants Linux, they know where to find it.

	- Dan C.

Re: [9fans] 'wall' messages

[Jim Choate]

On Tue, 7 Oct 2003, Bruce Ellis wrote:

> this solution works very well in practice, particularly if everyone
> runs seemail - the ominous bootes face herding everyone to
> the coffee machine.
>
> giving bootes some god-awful power to hijack other namespaces
> is not a very good solution.

Wait a minute, the users don't own those resources, they're borrowing
them. Within the context of the particular hardware it is completely
reasonable to leave bootes in control. Nobody is suggesting that bootes
necessarily be able to go out off that hardware and act as that user.

You're position basically lets the user have free reign over something
that isn't theirs. Yuck!


 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] 'wall' messages

[boyd]

yeah, like i just said in the #plan9 irc chat.

when you see the 'reboot of death' face you close up.

Re: [9fans] 'wall' messages

[Bruce Ellis]

this solution works very well in practice, particularly if everyone
runs seemail - the ominous bootes face herding everyone to
the coffee machine.

giving bootes some god-awful power to hijack other namespaces
is not a very good solution.

brucee
----- Original Message -----
From: <jmk@plan9.bell-labs.com>
To: <9fans@cse.psu.edu>
Sent: Tuesday, October 07, 2003 10:35 AM
Subject: Re: [9fans] 'wall' messages


> Send them mail from the console saying 'reboot at 21:00'.
> Put it in a file in /lib/news too so anyone just logging
> in or logging in afterwards knows what happened.

Re: [9fans] 'wall' messages

[Jim Choate]

On Mon, 6 Oct 2003 boyd@sdgm.net wrote:

>     Pity you can't do something like:
>
>     echo "WARNING: REBOOT AT 21:00" > /dev/display/* >> /lib/news
>
>     or something similar. Shouldn't each users display be accessible into
>     bootes' namespace for just this sort of stuff.
>
> one word: namespace

bootes should be able to alias into any users namespace on that box. That
means he should be able to export resources as well.

> 2nd work: permissions

bootes should be able to alias into any users namespace on that box. That
means he should be able to export resources as well.

> plumb/seemail could be a solution though.

Yep, let's add another layer of complexity. Another set of tools and
syntax.

Make it simple.

It should also work for sound so that somebody could,

play foo.mp3 > /dev/sound/*

And everyone who has their soundcard exported would get it. You could do
the same sort of thing with SMPT time codes, MIDI, USB, Firewire, I2C,
etc.

After all it is -just- a namespace.


 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] 'wall' messages

[Jim Choate]

On Mon, 6 Oct 2003 jmk@plan9.bell-labs.com wrote:

> Send them mail from the console saying 'reboot at 21:00'.
> Put it in a file in /lib/news too so anyone just logging
> in or logging in afterwards knows what happened.

Pity you can't do something like:

echo "WARNING: REBOOT AT 21:00" > /dev/display/* >> /lib/news

or something similar. Shouldn't each users display be accessible into
bootes' namespace for just this sort of stuff.


 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] 'wall' messages

[boyd]

    Pity you can't do something like:

    echo "WARNING: REBOOT AT 21:00" > /dev/display/* >> /lib/news

    or something similar. Shouldn't each users display be accessible into
    bootes' namespace for just this sort of stuff.

one word: namespace

2nd work: permissions

plumb/seemail could be a solution though.

Re: [9fans] 'wall' messages

[jmk]

Send them mail from the console saying 'reboot at 21:00'.
Put it in a file in /lib/news too so anyone just logging
in or logging in afterwards knows what happened.

Re: [9fans] 'wall' messages

[boyd]

reboot it.  say nothing.  i think sam etc will survive it.  no vi -r :)

[9fans] 'wall' messages

[mirtchov]

i have a few users logged in to a machine i'd really love to reboot
(say, because i'm adding an option to cpurc).  in a unix world i'd use
"wall" to tell them "reboot forthcoming in 5, 4, 3, 2, 1..." but in
plan 9 i can't do anything short of forcing them to listen to some
"announcement" file descriptor from /src...

how could i do something similar in Plan 9 with minimal effort?  i
know at some point it was customary to warn users by shouting across
the unix room, but some of the users here are rather far away...

andrey