Re: [9fans] from slashdot
http://www.unixreview.com/documents/s=9846/ur0508l/ur0508l.html Does this have any impact on Jim and Russ? Will this affect the sources and web infrastructure at all? Tim Newsham http://www.lava.net/~newsham/
[9fans] from slashdot
http://it.slashdot.org/article.pl?sid=05/08/16/2225215 Peter Salus over at UnixReview.com is reporting that AT&T Department 1127, responsible for creating and maintaining Unix, has been officially disbanded. The article provides an interesting "where are they now?" list of the original authors of Unix. and the article itself: http://www.unixreview.com/documents/s=9846/ur0508l/ur0508l.html text: Dept. 1127: going, Going, GONE! by Peter H. Salus In 1969, UNIX was created at Bell Labs. For decades, the source of the AT&T dialect of UNIX came from the researches of workers in department 1127. When the "Baby Bells" split from "Ma Bell," department 1127 survived. When AT&T and Lucent split, 1127 survived. But the new reorg at Bell Labs finally breaks up what's left of 1127 entirely. Theory people will go to one place, systems people to another, I'm told. I'm not sure what happens to those who fall in neither camp. There was no malice, so far as I can tell — just an administrative reorg forced by recent cutbacks and layoffs and departures that left the whole research area with too many managers and too few researchers. Ken Thompson retired to California. Brian Kernighan is a Professor at Princeton. Doug McIlroy is a Professor at Dartmouth. Rob Pike and Dave Presotto and Sean Dorward are at Google. Tom Duff is at Pixar. Phil Winterbottom is CTO at Entrisphere. Gerard Holzmann is at NASA/JPL Lab for Reliable Software. Bob Flandrena is at Morgan Stanley. To the best of my knowledge, Dennis Ritchie and Howard Trickey remain, enisled. A former employee at 1127 remarked: "My take is that 1127 probably reached Schiavo status when Rob, Presotto, et al. fled west to Google. "But it's still sad to see the final demise, both of a particular institution and as a further nail in the coffin of the sort of research environment Bell Labs once represented." That may be the worst effect. DEC Labs are gone. XEROX PARC transmogrified into "Palo Alto Research Center Inc." on 4 January 2002. It's a waning of research potential. Ave atque vale, guys. "And thanks for all the fish."
Re: [9fans] changing close()
On Tue, Aug 16, 2005 at 04:07:04AM -0400, Scott Schwartz wrote:
> | Is this a terrible idea? (I'm trying to address the lack of technical
> | discussion mentioned an earlier note :0)
>
> In my humble opinion, the better solution is to have dial return
> a pair of descriptors (and change the rest of the system to have
> e.g. /net/tcp/9/data{0,1}), so you can close the one you want.
>
> But maybe it's too late for that, and changing close is the only way.
I fancied having a 'split' call that would act a bit like a collision
between dup and pipe; it would return 2 fds - a read only and a write
only. So one could then do:
int bidir_fd;
int unidir_fds[2];
split(bidir_fd, unidir_fds);
close(bidir_fd);
/* Use unidir_fd[0] and unidir_fd[1] */
DF
Re: [9fans] changing close()
i said that the tcp implementation already had a "hangup" ctl message >>but that seems to assume that RST sent implies no further data can >>be received, which might not be right anyway. but when cooking the duck i remembered that it is right since it's sending RST not FIN. but a "fin" or "shutdown" message could be added if it really is important. i'm curious about the applications, though.
Re: [9fans] changing close()
In my version of Unix 7th Edition years ago I added another svc call to half close anything. It was a no-op on most files. I like the Tclink idea. What about a ½close call? --- Begin Message --- i wonder if it is common enough to want to change not only close but 9P (Tclunk would presumably change, or another message added such as T½clunk or Tclink). i think one reason it wasn't much used in old BSD is that most TCP/IP protocols have an application handshake at the end, two exceptions being now-deprecated BSD protocols. on the other hand, i grep and see that new BSD manages to use it in cat(!), and why not, and there are other uses, but only a few could be considered essential (mainly for those tcp/ip protocols i mentioned). inessential ones include a few preventing one part of the program from reading messages written by another part. still, that's not to say close-write hasn't got some merit if otherwise you can't do something important, but if its use is generally specific to particular protocols (applications), one might add a control message to ip/tcp.c with some consequential coding. in fact, it has "hangup" but that seems to assume that RST sent implies no further data can be received, which might not be right anyway. perhaps just changing that would do. of course, i'm making the assumption that the application must know these low-level properties, because application protocol assumes the network has them, so it won't work on just any type of connection. it isn't quite the same as with IL/IP because it just transmits write boundaries, so that as with 9 pipes zero isn't a special case, and it doesn't shut down any part of the link. oh. i see. their cat includes specific support for Unix-domain sockets (ifdef'd). what the ... oh. i see. it's because plain open doesn't work on them and gives EOPNOTSUPP?? not-quite-unix domain sockets? and there are two shutdown calls but only one is ever called, on a read-only file, which reduces it to close. i wondered if some of the other calls i saw are there because a networking book says to use shutdown. i saw shutdown(fd, 0); shutdown(fd, 1); ok, ok. sometimes there are ifdef's and conditionals round some of those, but still. --- End Message ---
Re: [9fans] Re: 9fans Digest, Vol 16, Issue 19
On Fri, Aug 12, 2005 at 09:16:16PM +0200, Unix wrote: > just wanted to say thanks, I finally got Plan 9 to install on my Compaq > AP550 with graphic, the FreeBSD bootloader didn't pick up Plan 9 > though..does anyone know if Grub will boot Plan 9? I have one host with grub chainloading the plan9 partition. It seems to work fine. That install seemed to break the Solaris 8 x86 bootloader, though. I don't know about the FreeBSD bootloader, but if "pick up" means autodetect, maybe it can still be configured to find plan9 and boot it. -- There's nothin' wrong with bein' a son of a bitch. -- Gaspode the dog
[9fans] aac/mp4 decoder
Hi, Anyone ported (or written native) an MP4 AAC audio decoder for plan9? -Steve
Re: [9fans] changing close()
i wonder if it is common enough to want to change not only close but 9P (Tclunk would presumably change, or another message added such as T½clunk or Tclink). i think one reason it wasn't much used in old BSD is that most TCP/IP protocols have an application handshake at the end, two exceptions being now-deprecated BSD protocols. on the other hand, i grep and see that new BSD manages to use it in cat(!), and why not, and there are other uses, but only a few could be considered essential (mainly for those tcp/ip protocols i mentioned). inessential ones include a few preventing one part of the program from reading messages written by another part. still, that's not to say close-write hasn't got some merit if otherwise you can't do something important, but if its use is generally specific to particular protocols (applications), one might add a control message to ip/tcp.c with some consequential coding. in fact, it has "hangup" but that seems to assume that RST sent implies no further data can be received, which might not be right anyway. perhaps just changing that would do. of course, i'm making the assumption that the application must know these low-level properties, because application protocol assumes the network has them, so it won't work on just any type of connection. it isn't quite the same as with IL/IP because it just transmits write boundaries, so that as with 9 pipes zero isn't a special case, and it doesn't shut down any part of the link. oh. i see. their cat includes specific support for Unix-domain sockets (ifdef'd). what the ... oh. i see. it's because plain open doesn't work on them and gives EOPNOTSUPP?? not-quite-unix domain sockets? and there are two shutdown calls but only one is ever called, on a read-only file, which reduces it to close. i wondered if some of the other calls i saw are there because a networking book says to use shutdown. i saw shutdown(fd, 0); shutdown(fd, 1); ok, ok. sometimes there are ifdef's and conditionals round some of those, but still.
Re: [9fans] changing close()
| Is this a terrible idea? (I'm trying to address the lack of technical
| discussion mentioned an earlier note :0)
In my humble opinion, the better solution is to have dial return
a pair of descriptors (and change the rest of the system to have
e.g. /net/tcp/9/data{0,1}), so you can close the one you want.
But maybe it's too late for that, and changing close is the only way.
