Re: [9fans] kerberos for plan9
On Wed, Oct 22, 2008 at 4:41 PM, Sergey Zhilkin [EMAIL PROTECTED] wrote: Ohh, those Russians :) 2008/10/20 Sevan / Venture37 [EMAIL PROTECTED] has anyone looked into this? i found this by a group in Spain, though not what i expected ☺ Kerberos (7) - Plan 9 From Outer Space http://www.discogs.com/release/1294855 http://www.discogs.com/artist/SCSI-9?anv=SCSI+9 _ Win an Xbox 360 or £200 Top Shop Vouchers http://clk.atdmt.com/GBL/go/115454062/direct/01/ -- С Уважением Жилкин Сергей Actually they are pretty cool russians. Few years ago when I first heard about Scsi-9 (didn't know about plan9 yet) if I remember correctly they released stuff at Kompakt or Trapez/Traum. You still hear their stuff being played from time to time here in cologne's clubs. Does someone have the kerberos stuff digitalized? Is it worth it?
Re: [9fans] sources down?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 2, 2008, at 1:51 PM, Skip Tavakkolian wrote: [blank message] The strangest part? It's been down since this morning (I'm on Murray Hill time here on Long Island); longer than usual. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkN+ccACgkQuv7AVNQDs+w/ngCfVIjCGT18ZDUNV6/uynighKDM dtgAnjJVMoDnAdfV0YN0wFdzhW4fhYbZ =gcnp -END PGP SIGNATURE-
Re: [9fans] sources down?
On Sun, Nov 2, 2008 at 15:35, [EMAIL PROTECTED] wrote: Sources is back up. We had a power outage and some of our machines didn't come back up automatically, though they usually do. and here i was thinking you had taken them offline to retool them for standard time ☺. thank you for maintaining sources. it is an invaluable resource -- m
Re: [9fans] sources down?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 2, 2008, at 4:58 PM, michael block wrote: retool them for standard time isn't that done automatically? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkOO7wACgkQuv7AVNQDs+yHxgCgqfsq+xr9i710y0c0Wogr7OIT JpEAoKIGJAe0FvG0ZX+muMnDimc6KoAe =sVbs -END PGP SIGNATURE-
Re: [9fans] mmap
* Roman V. Shaposhnik [EMAIL PROTECTED] wrote: On Wed, 2008-07-30 at 17:29 +0200, Enrico Weigelt wrote: Convenience is one point (sometimes be a big point), but another important one is sharing. Without mmap(), an (real) shared library support most likely will require special kernel support. What aspect of shared libraries are you aching for? Dynamic linking or the dynamic loading? 3rd: Sharing pages. Well, this perhaps also could be done if the kernel would be able to detect equal pages and automatically map them together (maybe w/ copy-on-write again). BTW mmap() is also nice for creating shared memory between (local) processes. For example RDBMS'es can get a huge benetit from this. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [9fans] mmap
* Roman V. Shaposhnik [EMAIL PROTECTED] wrote: On Wed, 2008-07-30 at 17:29 +0200, Enrico Weigelt wrote: Convenience is one point (sometimes be a big point), but another important one is sharing. Without mmap(), an (real) shared library support most likely will require special kernel support. What aspect of shared libraries are you aching for? Dynamic linking or the dynamic loading? 3rd: Sharing pages. segment(3) already provides this. - erik
Re: [9fans] mmap
On Sun, Nov 2, 2008 at 5:50 PM, erik quanstrom [EMAIL PROTECTED] wrote: * Roman V. Shaposhnik [EMAIL PROTECTED] wrote: On Wed, 2008-07-30 at 17:29 +0200, Enrico Weigelt wrote: Convenience is one point (sometimes be a big point), but another important one is sharing. Without mmap(), an (real) shared library support most likely will require special kernel support. What aspect of shared libraries are you aching for? Dynamic linking or the dynamic loading? 3rd: Sharing pages. segment(3) already provides this. I still remember this science fiction movie from when I was a kid. Time travelers. At the end of the movie, you realized that they were ending at the point where they were started, stuck in a loop, oh no! and here we are at mmap again. ron
Re: [9fans] mv on directory
On Nov 1, 2008, at 7:12 PM, Eric Van Hensbergen wrote: On Sat, Nov 1, 2008 at 4:05 PM, Roman Shaposhnik [EMAIL PROTECTED] wrote: On Nov 1, 2008, at 8:04 AM, Eric Van Hensbergen wrote: I would imagine that 99% of the time (more?) the behavior people desire would be what you describe. But what is the behavior? Is it literally the above set of rc commands? Or is there an atomicity expectation as well? After dircp dirA dirB the contents of dirB could be surprising, especially given the later rm -r dirA. It seems that mv(1) was taken as far as one could go in terms of having a non-surprising behavior: mv dir1/file dir2/file is equivalent to cp -x dir1/file dir2/file ; rm dir1/file. Well, I suppose there'd have to be a bit more wrapping around checking for failure of the copy before the erase -- but otherwise perhaps I'm being dense and don't see the surprise. Well, it could be that I'm just too easily surprised. I'll try to explain. Suppose that you have the following sequence of directory renames (all within the single FS tree): (1) /a -/b (2) /a/1 -/a/2 Because of the POSIX atomicity guarantee the minute you have (1) succeed your (2) will fail because /a/1 no longer exists. The following, on the other hand: (1) mv-dircp /a /b (2) mv-dircp /a/1 /a/2 is likely to produce /b/2, which, I find surprising. As a side note: the results are even more surprising/subtle when renames need to be serialized in a DSCM. There's been quite a few debates on what DSCM does it better. Just like Al said -- somebody at UCB had one heck of a trip ;-) Its clear you won't get the atomicity, but there's no clear way to obtain that -- and, as I said, I'm not sure who depends on that when using the mv command. I would argue that personally I've been conditioned by POSIX to be able to do: $ mv root of the huge file hierarchy .hidden-from-everybody and expect all references to anything in the original file hierarchy to fail from that point on. Thanks, Roman.
Re: [9fans] mmap
* erik quanstrom [EMAIL PROTECTED] wrote: * Roman V. Shaposhnik [EMAIL PROTECTED] wrote: On Wed, 2008-07-30 at 17:29 +0200, Enrico Weigelt wrote: Convenience is one point (sometimes be a big point), but another important one is sharing. Without mmap(), an (real) shared library support most likely will require special kernel support. What aspect of shared libraries are you aching for? Dynamic linking or the dynamic loading? 3rd: Sharing pages. segment(3) already provides this. hmm, so segment(3)+segattach(2) can be seen as a kind of a frontend for mmap() ;-) But now I'm curious how executables and shared libraries are actually handled on plan9. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [9fans] mmap
On Sun, Nov 2, 2008 at 8:18 PM, Enrico Weigelt [EMAIL PROTECTED] wrote: But now I'm curious how executables and shared libraries are actually handled on plan9. what's a shared library? Executables: /sys/src/9/ Check it out, it's short and sweet. ron
[9fans] Questions on notes
Guys,
I've been experimenting with how Plan 9 handles notes for processes and
I must confess that I'm now confused and in need your help.
First of all, the proc(3) man page says that A read [from /proc/n/
note] of at least ERRLEN
characters will retrieve the oldest note posted to the process and
prevent its delivery to
the process and for some reason I have always assumed that the read
would be a blocking
one. Yet, it doesn't seem to be the case:
term% dd -if /proc/1/note -bs 256
0+0 record in
0+0 records out
A visit to /sys/src/9/port/devproc.c confirms that if there are no
notes any read immediately
return with 0. At this point the whole idea of letting an external
process read notes suddenly
becomes much less appealing: the only option left to the reader is
constant polling(*). On
top of that there always seems to be a race condition between somebody
reading on /proc/n/note
and the scheduler actually delivering a note via the call to a
handler. These two things
make me the following question: what is the point of reading /proc/n/
note for anything but a
stopped/borken process?
Thanks,
Roman.
(*) Speaking of constant polling: the following hangs 9vx for good on
my system:
term% cat test.c
#include u.h
#include libc.h
void door_bell(void* dummy, char* note)
{
print(look who's there: %s\n, note);
noted(NCONT);
}
int main()
{
char buf[256];
int fd,i;
sprint(buf, /proc/%d/note, getpid());
fd = open(buf, OREAD);
notify(door_bell);
print(starting up: %d\n, fd);
for (;;) {
if ((i = read(fd, buf, sizeof(buf))) 0)
break;
if (i)
print(selfserving: %s\n, buf);
}
return 0;
}
term% 8c test.c ; 8l test.8 ; ./8.out
EVERYTHING IS DEAD AT THIS POINT
Re: [9fans] mmap
I still remember this science fiction movie from when I was a kid. which one was that? it sounds more interesting than mmap.
Re: [9fans] mmap
On Sun, Nov 2, 2008 at 11:29 PM, Charles Forsyth [EMAIL PROTECTED] wrote: I still remember this science fiction movie from when I was a kid. which one was that? it sounds more interesting than mmap. I wish I could remember. It had the usual guys in silvery suits. They walk through a frame and are back in time. Key point was, at the end, that they ended up escaping but for reasons unknown, walking back through the frame -- bad idea. ron
[9fans] punched cards live
This courtesy of the ACPI spec: RSD PTR (Notice that this signature must contain a trailing blank character.) So where do we get the guys who design this stuff? Can we send them back? Or put them in an infinite loop in a time machine (oh wait see the subject). ron
Re: [9fans] volos experiment
well the experiment description should include - each with a significantly large backpack-. 2008/11/3 Andrew Simmons [EMAIL PROTECTED]: how many 9fans can you fit in a small hotel room in Βόλος before the management get upset? If the first 9fan is Boyd packing his normal weaponry, I would imagine the answer is at most one. Ditto for a large hotel room anywhere in the world.
