* [TUHS] FD 2 @ 2023-01-20 22:44 ron minnich 2023-01-20 22:54 ` [TUHS] " G. Branden Robinson ` (4 more replies) 0 siblings, 5 replies; 69+ messages in thread From: ron minnich @ 2023-01-20 22:44 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 130 bytes --] I am trying to remember when fd 2 (aka stderr) became a thing. I have a vague memory that it was post-v6 but that may be way off. [-- Attachment #2: Type: text/html, Size: 185 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-20 22:44 [TUHS] FD 2 ron minnich @ 2023-01-20 22:54 ` G. Branden Robinson 2023-01-20 22:56 ` Rob Pike ` (3 subsequent siblings) 4 siblings, 0 replies; 69+ messages in thread From: G. Branden Robinson @ 2023-01-20 22:54 UTC (permalink / raw) To: ron minnich; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 330 bytes --] At 2023-01-20T14:44:51-0800, ron minnich wrote: > I am trying to remember when fd 2 (aka stderr) became a thing. I have > a vague memory that it was post-v6 but that may be way off. The story goes that it swiftly followed the creation of troff. https://minnie.tuhs.org/pipermail/tuhs/2013-December/006113.html Regards, Branden [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-20 22:44 [TUHS] FD 2 ron minnich 2023-01-20 22:54 ` [TUHS] " G. Branden Robinson @ 2023-01-20 22:56 ` Rob Pike 2023-01-20 23:11 ` Larry McVoy 2023-01-20 23:13 ` Douglas McIlroy ` (2 subsequent siblings) 4 siblings, 1 reply; 69+ messages in thread From: Rob Pike @ 2023-01-20 22:56 UTC (permalink / raw) To: ron minnich; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 745 bytes --] I will let others respond with specifics, but that was there in v5 at least. One of the many shocks I had on arrival at Google was that in production, fd2 was pretty much standard output, as all the logging went there. And since our machines were still 32-bit CPUs then, it was common to overflow the offset because the logging output was, well, not parsimonious. It felt like I'd entered bizarro world, until I realized that few anywhere really knew how Unix was supposed to be used. And they still don't, and never will. -rob On Sat, Jan 21, 2023 at 9:46 AM ron minnich <rminnich@gmail.com> wrote: > I am trying to remember when fd 2 (aka stderr) became a thing. I have a > vague memory that it was post-v6 but that may be way off. > > > [-- Attachment #2: Type: text/html, Size: 1503 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-20 22:56 ` Rob Pike @ 2023-01-20 23:11 ` Larry McVoy 2023-01-20 23:14 ` Rob Pike 0 siblings, 1 reply; 69+ messages in thread From: Larry McVoy @ 2023-01-20 23:11 UTC (permalink / raw) To: Rob Pike; +Cc: The Eunuchs Hysterical Society On Sat, Jan 21, 2023 at 09:56:16AM +1100, Rob Pike wrote: > I will let others respond with specifics, but that was there in v5 at least. > > One of the many shocks I had on arrival at Google was that in production, > fd2 was pretty much standard output, as all the logging went there. And > since our machines were still 32-bit CPUs then, it was common to overflow > the offset because the logging output was, well, not parsimonious. It felt > like I'd entered bizarro world, until I realized that few anywhere really > knew how Unix was supposed to be used. And they still don't, and never will. Isn't there a logging API complete with the ability to centralize the logs? ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-20 23:11 ` Larry McVoy @ 2023-01-20 23:14 ` Rob Pike 2023-01-20 23:22 ` Larry McVoy 0 siblings, 1 reply; 69+ messages in thread From: Rob Pike @ 2023-01-20 23:14 UTC (permalink / raw) To: Larry McVoy; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 829 bytes --] Yes, but everyone adds the flag --alsologtostderr -rob On Sat, Jan 21, 2023 at 10:11 AM Larry McVoy <lm@mcvoy.com> wrote: > On Sat, Jan 21, 2023 at 09:56:16AM +1100, Rob Pike wrote: > > I will let others respond with specifics, but that was there in v5 at > least. > > > > One of the many shocks I had on arrival at Google was that in production, > > fd2 was pretty much standard output, as all the logging went there. And > > since our machines were still 32-bit CPUs then, it was common to overflow > > the offset because the logging output was, well, not parsimonious. It > felt > > like I'd entered bizarro world, until I realized that few anywhere really > > knew how Unix was supposed to be used. And they still don't, and never > will. > > Isn't there a logging API complete with the ability to centralize the logs? > [-- Attachment #2: Type: text/html, Size: 1449 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-20 23:14 ` Rob Pike @ 2023-01-20 23:22 ` Larry McVoy 0 siblings, 0 replies; 69+ messages in thread From: Larry McVoy @ 2023-01-20 23:22 UTC (permalink / raw) To: Rob Pike; +Cc: The Eunuchs Hysterical Society That's dumb. Though I run slack like so slack > /dev/null 2>&1 & because whatever version I have spews garbage to stderr. Sigh. On Sat, Jan 21, 2023 at 10:14:25AM +1100, Rob Pike wrote: > Yes, but everyone adds the flag --alsologtostderr > > -rob > > > On Sat, Jan 21, 2023 at 10:11 AM Larry McVoy <lm@mcvoy.com> wrote: > > > On Sat, Jan 21, 2023 at 09:56:16AM +1100, Rob Pike wrote: > > > I will let others respond with specifics, but that was there in v5 at > > least. > > > > > > One of the many shocks I had on arrival at Google was that in production, > > > fd2 was pretty much standard output, as all the logging went there. And > > > since our machines were still 32-bit CPUs then, it was common to overflow > > > the offset because the logging output was, well, not parsimonious. It > > felt > > > like I'd entered bizarro world, until I realized that few anywhere really > > > knew how Unix was supposed to be used. And they still don't, and never > > will. > > > > Isn't there a logging API complete with the ability to centralize the logs? > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-20 22:44 [TUHS] FD 2 ron minnich 2023-01-20 22:54 ` [TUHS] " G. Branden Robinson 2023-01-20 22:56 ` Rob Pike @ 2023-01-20 23:13 ` Douglas McIlroy 2023-01-21 3:37 ` Jon Steinhart 2023-01-21 15:42 ` Clem Cole 4 siblings, 0 replies; 69+ messages in thread From: Douglas McIlroy @ 2023-01-20 23:13 UTC (permalink / raw) To: ron minnich; +Cc: The Eunuchs Hysterical Society Yes. It is confirmed by a change in the init man page between v6 and v7. This can be seen in the TUHS archive. On Fri, Jan 20, 2023 at 5:46 PM ron minnich <rminnich@gmail.com> wrote: > > I am trying to remember when fd 2 (aka stderr) became a thing. I have a vague memory that it was post-v6 but that may be way off. > > ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-20 22:44 [TUHS] FD 2 ron minnich ` (2 preceding siblings ...) 2023-01-20 23:13 ` Douglas McIlroy @ 2023-01-21 3:37 ` Jon Steinhart 2023-01-21 15:42 ` Clem Cole 4 siblings, 0 replies; 69+ messages in thread From: Jon Steinhart @ 2023-01-21 3:37 UTC (permalink / raw) To: The Eunuchs Hysterical Society ron minnich writes: > I am trying to remember when fd 2 (aka stderr) became a thing. I have a > vague memory that it was post-v6 but that may be way off. Related to this, according to Steve Johnson, stderr was not part of the original stdio library; it was added as a side effect of the development of troff for the C/A/T photoypesetter which projected images onto silver photographic paper. That became very expensive when the Hunt brothers cornered the silver market, and folks were asked to cut down on phototypesetter use. It was not uncommon to send a job to the typesetter only to get back a beautifully formatted page containing a cannot open file error message. The stderr file pointer was born so that error messages could go to the terminal instead of to the typesetter in order to save money. ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-20 22:44 [TUHS] FD 2 ron minnich ` (3 preceding siblings ...) 2023-01-21 3:37 ` Jon Steinhart @ 2023-01-21 15:42 ` Clem Cole 2023-01-21 17:34 ` Warner Losh 4 siblings, 1 reply; 69+ messages in thread From: Clem Cole @ 2023-01-21 15:42 UTC (permalink / raw) To: ron minnich; +Cc: The Eunuchs Hysterical Society [-- Attachment #1.1: Type: text/plain, Size: 1673 bytes --] Certainly fd 2 as a error output appears with Lesk's portable C library, which was included in V6 - see the last para on page 1 of his document: "Initially you are given three file descriptors by the system: 0, 1, and 2. File 0 is the standard input; it is normally the teletype in time-sharing or input data cards in batch. File 1 is the standard output; it is nor- mally the teletype in time-sharing or the line printer in batch. File 2 is the error file; it is an output file, nor- mally the same as file 1, except that when file 1 is diverted via a command line ’>’ operator, file 2 remains attached to the original destination, usually the terminal. It is used for error message output. These popular UNIX conventions are considered part of the C library specification. By closing 0 or 1, the default input or output may be re-directed; this can also be done on the command line by >file for output or <file for input." This document pre-dates ditroff. The idea/names of stdin/out/err (as opposed to fd 0, 1, 2) does not come about until Dennis does "typesetter C" which is described in K&R. That said, my memory is fd 2 as ana error path was there in Fourth or Fifth Edition, before Lesk did this library -- i.e. it was a convention that Dennis/Ken et al were all using -- when it is realized that printing errors on in the same output flow as the standard (normal) output was problematic in a pipe stream. ᐧ On Fri, Jan 20, 2023 at 5:46 PM ron minnich <rminnich@gmail.com> wrote: > I am trying to remember when fd 2 (aka stderr) became a thing. I have a > vague memory that it was post-v6 but that may be way off. > > > [-- Attachment #1.2: Type: text/html, Size: 3391 bytes --] [-- Attachment #2: iolib.pdf --] [-- Type: application/pdf, Size: 46203 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-21 15:42 ` Clem Cole @ 2023-01-21 17:34 ` Warner Losh 2023-01-21 17:50 ` Warner Losh 2023-01-21 18:27 ` Clem Cole 0 siblings, 2 replies; 69+ messages in thread From: Warner Losh @ 2023-01-21 17:34 UTC (permalink / raw) To: Clem Cole; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 2027 bytes --] On Sat, Jan 21, 2023, 8:45 AM Clem Cole <clemc@ccc.com> wrote: > Certainly fd 2 as a error output appears with Lesk's portable C library, > which was included in V6 - see the last para on page 1 of his document: > > "Initially you are given three file descriptors by the system: 0, 1, and > 2. File 0 is the standard input; it is normally the teletype in > time-sharing or input data cards in batch. File 1 is the standard output; > it is nor- mally the teletype in time-sharing or the line printer in batch. > File 2 is the error file; it is an output file, nor- mally the same as file > 1, except that when file 1 is diverted via a command line ’>’ operator, > file 2 remains attached to the original destination, usually the terminal. > It is used for error message output. These popular UNIX conventions are > considered part of the C library specification. By closing 0 or 1, the > default input or output may be re-directed; this can also be done on the > command line by >file for output or <file for input." > > This document pre-dates ditroff. The idea/names of stdin/out/err (as > opposed to fd 0, 1, 2) does not come about until Dennis does "typesetter C" > which is described in K&R. > > That said, my memory is fd 2 as ana error path was there in Fourth or > Fifth Edition, before Lesk did this library -- i.e. it was a convention > that Dennis/Ken et al were all using -- when it is realized that printing > errors on in the same output flow as the standard (normal) output was > problematic in a pipe stream. > ᐧ > It looks to be a mixed bag in 5th edition. Cc, ac, comm and find all printf the errors. Diff uses writes to fd 2. I didn't catalog further, but this kinda looks like a developing convention, not yet fully realized. . Warner On Fri, Jan 20, 2023 at 5:46 PM ron minnich <rminnich@gmail.com> wrote: > >> I am trying to remember when fd 2 (aka stderr) became a thing. I have a >> vague memory that it was post-v6 but that may be way off. >> >> >> [-- Attachment #2: Type: text/html, Size: 4227 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-21 17:34 ` Warner Losh @ 2023-01-21 17:50 ` Warner Losh 2023-01-21 18:26 ` Clem Cole 2023-01-21 18:27 ` Clem Cole 1 sibling, 1 reply; 69+ messages in thread From: Warner Losh @ 2023-01-21 17:50 UTC (permalink / raw) To: Clem Cole; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 2518 bytes --] On Sat, Jan 21, 2023, 10:34 AM Warner Losh <imp@bsdimp.com> wrote: > > > On Sat, Jan 21, 2023, 8:45 AM Clem Cole <clemc@ccc.com> wrote: > >> Certainly fd 2 as a error output appears with Lesk's portable C library, >> which was included in V6 - see the last para on page 1 of his document: >> >> "Initially you are given three file descriptors by the system: 0, 1, and >> 2. File 0 is the standard input; it is normally the teletype in >> time-sharing or input data cards in batch. File 1 is the standard output; >> it is nor- mally the teletype in time-sharing or the line printer in batch. >> File 2 is the error file; it is an output file, nor- mally the same as file >> 1, except that when file 1 is diverted via a command line ’>’ operator, >> file 2 remains attached to the original destination, usually the terminal. >> It is used for error message output. These popular UNIX conventions are >> considered part of the C library specification. By closing 0 or 1, the >> default input or output may be re-directed; this can also be done on the >> command line by >file for output or <file for input." >> >> This document pre-dates ditroff. The idea/names of stdin/out/err (as >> opposed to fd 0, 1, 2) does not come about until Dennis does "typesetter C" >> which is described in K&R. >> >> That said, my memory is fd 2 as ana error path was there in Fourth or >> Fifth Edition, before Lesk did this library -- i.e. it was a convention >> that Dennis/Ken et al were all using -- when it is realized that printing >> errors on in the same output flow as the standard (normal) output was >> problematic in a pipe stream. >> ᐧ >> > > It looks to be a mixed bag in 5th edition. Cc, ac, comm and find all > printf the errors. Diff uses writes to fd 2. I didn't catalog further, but > this kinda looks like a developing convention, not yet fully realized. . > Further digging shows v6 is quite similar. V7 revamps everything, with printf changed to a routine that writes to stderr. Each program did this differently. Granted, this is a small sample size. There wasn't a huge uptake of stderr/fd2 in v6 it seems, but v7 looks like it had a pass over the code to at least try for all errors going to fd2. Warner > Warner > > On Fri, Jan 20, 2023 at 5:46 PM ron minnich <rminnich@gmail.com> wrote: >> >>> I am trying to remember when fd 2 (aka stderr) became a thing. I have a >>> vague memory that it was post-v6 but that may be way off. >>> >>> >>> [-- Attachment #2: Type: text/html, Size: 5323 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-21 17:50 ` Warner Losh @ 2023-01-21 18:26 ` Clem Cole 2023-01-21 18:37 ` Warner Losh 0 siblings, 1 reply; 69+ messages in thread From: Clem Cole @ 2023-01-21 18:26 UTC (permalink / raw) To: Warner Losh; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 2436 bytes --] On Sat, Jan 21, 2023 at 12:50 PM Warner Losh <imp@bsdimp.com> wrote: > > Further digging shows v6 is quite similar. > As I said, by then they know it's an issue and the fd 2 has been introduced. The place to look is not the utilities, but the shell itself and what the kernel is doing in newproc et al for the tty handler. > V7 revamps everything, with printf changed to a routine that writes to > stderr. Each program did this differently. > IMO: Sort of two different things >>I think<<. They are related - the idea ( what the OS supplied to each process), as opposed to what/how each utility handled it. With typesetter C -- we get dmr's new stdio library (libS.a) replacing Lesk's portable C library. This was released independent of V6 as what DEC would have called a 'layered product" that ran on top of V6. As I said, this is the language that Dennis and Brian describe in K&R (version 1). With what was becoming UNIX/TS -- which don't seem to have a formal release -- we get what we all think of as the V7 kernel, Bourne's new shell and the new and updated tools suite as part of the system. So with V7, as you point out, most, but not all of the utilities have been updated to start using the new compiler (since by then Lesk library is not included), If the code were recompiled, that code would have had to used the new FILE * structure over the small integer fd, for the printf family. With V6 there were still a handful of utilities in assembler (like snoball IIRC), but by V7 I think most of them had been culled. And while your point is that you need to look at what each utility implemented, >>I believe<< that the key to Ron's question is what the shell and the kernel supplied [dates the idea], and >>then<< if the utility obeyed the new fd 2 as the error file is when it starts to be more formally enforced. So any further hunting should start there I would think. Clem > > Granted, this is a small sample size. There wasn't a huge uptake of > stderr/fd2 in v6 it seems, but v7 looks like it had a pass over the code to > at least try for all errors going to fd2. > > Warner > > >> Warner >> >> On Fri, Jan 20, 2023 at 5:46 PM ron minnich <rminnich@gmail.com> wrote: >>> >>>> I am trying to remember when fd 2 (aka stderr) became a thing. I have a >>>> vague memory that it was post-v6 but that may be way off. >>>> >>>> >>>> ᐧ [-- Attachment #2: Type: text/html, Size: 5659 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-21 18:26 ` Clem Cole @ 2023-01-21 18:37 ` Warner Losh 2023-01-22 11:05 ` Jonathan Gray 2023-01-22 21:23 ` Warner Losh 0 siblings, 2 replies; 69+ messages in thread From: Warner Losh @ 2023-01-21 18:37 UTC (permalink / raw) To: Clem Cole; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 3216 bytes --] On Sat, Jan 21, 2023, 11:26 AM Clem Cole <clemc@ccc.com> wrote: > > > On Sat, Jan 21, 2023 at 12:50 PM Warner Losh <imp@bsdimp.com> wrote: > > >> >> Further digging shows v6 is quite similar. >> > As I said, by then they know it's an issue and the fd 2 has been > introduced. The place to look is not the utilities, but the shell itself > and what the kernel is doing in newproc et al for the tty handler. > The utilities were all using printf so even if the concept was there, it wasn't widely used. I'll take a longer look, including these places.. though I'm not sure I see the connection to the tty driver... V7 revamps everything, with printf changed to a routine that writes to >> stderr. Each program did this differently. >> > IMO: Sort of two different things >>I think<<. They are related - the idea > ( what the OS supplied to each process), as opposed to what/how each > utility handled it. > Yea. Mostly i think each program had a different wrapper around stderr to minimize changes to the program... With typesetter C -- we get dmr's new stdio library (libS.a) replacing > Lesk's portable C library. This was released independent of V6 as what DEC > would have called a 'layered product" that ran on top of V6. As I said, > this is the language that Dennis and Brian describe in K&R (version 1). > Do we have extant copies of that? So far I have see the kernel patches that were "leaked" but not the rest of it. With what was becoming UNIX/TS -- which don't seem to have a formal release > -- we get what we all think of as the V7 kernel, Bourne's new shell and the > new and updated tools suite as part of the system > Yea. So with V7, as you point out, most, but not all of the utilities have been > updated to start using the new compiler (since by then Lesk library is not > included), If the code were recompiled, that code would have had to used > the new FILE * structure over the small integer fd, for the printf family. > With V6 there were still a handful of utilities in assembler (like snoball > IIRC), but by V7 I think most of them had been culled. > > And while your point is that you need to look at what each utility > implemented, >>I believe<< that the key to Ron's question is what the shell > and the kernel supplied [dates the idea], and >>then<< if the utility > obeyed the new fd 2 as the error file is when it starts to be more formally > enforced. So any further hunting should start there I would think. > Yea. Like many things, there was a transition... the most important bit is the shell. And that was more tricky to read through with the phone at breakfast... Warner Clem > > > >> >> Granted, this is a small sample size. There wasn't a huge uptake of >> stderr/fd2 in v6 it seems, but v7 looks like it had a pass over the code to >> at least try for all errors going to fd2. >> >> Warner >> >> >>> Warner >>> >>> On Fri, Jan 20, 2023 at 5:46 PM ron minnich <rminnich@gmail.com> wrote: >>>> >>>>> I am trying to remember when fd 2 (aka stderr) became a thing. I have >>>>> a vague memory that it was post-v6 but that may be way off. >>>>> >>>>> >>>>> ᐧ > [-- Attachment #2: Type: text/html, Size: 7775 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-21 18:37 ` Warner Losh @ 2023-01-22 11:05 ` Jonathan Gray 2023-01-22 21:23 ` Warner Losh 1 sibling, 0 replies; 69+ messages in thread From: Jonathan Gray @ 2023-01-22 11:05 UTC (permalink / raw) To: Warner Losh; +Cc: tuhs On Sat, Jan 21, 2023 at 11:37:42AM -0700, Warner Losh wrote: > On Sat, Jan 21, 2023, 11:26 AM Clem Cole <clemc@ccc.com> wrote: > > With typesetter C -- we get dmr's new stdio library (libS.a) replacing > > Lesk's portable C library. This was released independent of V6 as what DEC > > would have called a 'layered product" that ran on top of V6. As I said, > > this is the language that Dennis and Brian describe in K&R (version 1). > > > > Do we have extant copies of that? So far I have see the kernel patches that > were "leaked" but not the rest of it. Of the "Phototypesetter Version 7" tape? The compiler and stdio show up in other places before v7. libp/iolib described in M. E. Lesk - The Portable C Library https://archive.org/details/ThePortableCLibrary_May75 (abbreviated in https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/doc/iolib/iolib ) libS/stdio appears in a modified form in PWB/UNIX 1.0 As does "A New Input-Output Package" https://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s4/stdio/ios.r included in "Documents for the PWB/UNIX Time-Sharing System Edition 1.0" https://bitsavers.org/pdf/att/unix/PWB_UNIX/Documents_for_the_PWB_UNIX_Time-Sharing_System_Edition_1.0_197710.pdf an older? version appears in tuhs/Applications/Spencer_Tapes/unsw3.tar.gz usr/source/stdio also part of https://minnie.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/source/stdio https://minnie.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/doc/cdoc/ios.nr tuhs/Distributions/Research/Tim_Shoppa_v6 (libS, stdio.h, no libS source) and MERT Release 0, NEWIO(III) newio - a new IO subroutine package https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Unix%20Programmer%20Manual%20-%20UPM%20-%20White%20Tabs/Subroutines%20-%20man3/newio.3.pdf "part of the effort in moving programs to the Interdata machine was devoted to making programs use the new standard I/O library" S. C. Johnson, D. M. Ritchie - Portability of C Programs and the UNIX System https://www.bell-labs.com/usr/dmr/www/portpap.html "In the first sense, the portability of C programs have been recently enhanced by new tools developed by center 127: ... * The Standard I/O package implements efficient portable I/O. This package should be used for nearly all new C development. The bulk of existing programs should be converted, as well." B. A. Tague - C Language Portability https://archive.org/details/CLanguagePortability_Sept77 "2.2 The Standard I/O Library In the past, there were two I/O libraries available. One was documented by A New Input-Output Package (Ritchie), and was made available through the -lS loader option. The other, older one was made available whenever a C program was being compiled; it was characterized, among other things, by use of the names fin and fout to control disposition of standard input and output files. The older library has now vanished, along with the -lS option. All programs will receive the new I/O library without any explicit action. In addition, the libraries obtained by -lc and -la have been merged; this combined library is accessed (where needed) by -lc or -l." Andrew R. Koenig - The C Environment of UNIX/TS https://bitsavers.org/pdf/plexus/Sys3/98-05036.5_Plexus_Sys3_UNIX_Programmers_Manual_Vol_2A_RevA_198409.pdf "New archiver ... uses long (double-word) integers, which can only be compiled by the new C compiler which we can't distribute yet." UNIX News, May-June 1976, 6-3 https://www.tuhs.org/Archive/Documentation/Usenix/Early_Newsletters/197605-unix-news-n6.pdf "a new tape is in the process of preparation, and should be available as soon as it clears the lawyers, for the usual free license and handling fee. It contains the new nroff, the new C, the new I/O library (faster & smaller than anything to date), and a bunch of other such things. It will be available from Bell, not the Center. Ken is going to send a formal notice to the News." UNIX News, November 1976, pg 1 https://www.tuhs.org/Archive/Documentation/Usenix/Early_Newsletters/197611-unix-news-n11.pdf 'Among the items listed are mini-UNIX (previously announced) and "PHOTOTYPESETTER VERSION 7" which is new.' https://www.tuhs.org/Archive/Documentation/Usenix/Early_Newsletters/197703-unix-news-v2n3.pdf "The principal speaker at the Phototypesetting session was Joe Ossana. He announced a new phototypesetting package, typesetter V7, which is or soon will be available from Western Electric for a $3300 license fee. The new package combines NROFF and TROFF and is written in C." https://archive.org/details/login_august-1977/page/n21/mode/2up https://www.usenix.org/system/files/login/articles/login_dec15_11_history_login.pdf https://www.bell-labs.com/usr/dmr/www/licenses/pricelist84.pdf has different items for "Phototypesetter Programmer's Workbench" "Phototypesetter V7" "Independent TROFF" these are also mentioned in https://archive.org/details/login_april83_issue/page/n13/mode/2up "On November 1, 1977 Toronto received a license for Phototypesetter V7" Salus QCU pg 123 ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-21 18:37 ` Warner Losh 2023-01-22 11:05 ` Jonathan Gray @ 2023-01-22 21:23 ` Warner Losh 2023-01-22 22:10 ` ron minnich ` (2 more replies) 1 sibling, 3 replies; 69+ messages in thread From: Warner Losh @ 2023-01-22 21:23 UTC (permalink / raw) To: Clem Cole; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1708 bytes --] On Sat, Jan 21, 2023 at 11:37 AM Warner Losh <imp@bsdimp.com> wrote: > > Yea. Like many things, there was a transition... the most important bit is > the shell. And that was more tricky to read through with the phone at > breakfast... > OK. I've dug a bit further and Clem and I have chatted... Here's the summary. We don't have V4's shell, alas, since all we have from that time period is the C kernel a few months before the 4th edition release. V5 /bin/sh closes fd2 and then dups fd1 to fd2. This creates fd2 as something special. V6 closes all FD's larger than 1 (2-15) and then does the dup(1) which it makes sure returns 2 or it closes the file. While there were features in V6 to allow use of fd2/stderr, few programs used then. And neither crypt nor passwd reads from fd2. crypt reads from fd0, while passwd doesn't read. It just replaces the hashed password with the new password. I've also looked at pr because >I do remember that pr -p actually read from FD 2. It probably still does. and that's not true in V7 at least... pr didn't have a 'p' arg :). Maybe later programs started to do these things, but most of what went on with V7 was a transition to most error messages on stderr, which typically went to stdout in V6. So, people remembering it coming in with V7 are right, in the sense it was the first release to do it consistently. And the people remembering V4 or V5 are also right, in a different sense because the shell was ensuring fd2 was a copy of fd1 there, which a couple of programs (diff) used for errors. And I believe that the impetus for the V7 changes was phototypesetting 'file not found' too often... But that last bit is mostly because I want to believe. Warner [-- Attachment #2: Type: text/html, Size: 2402 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-22 21:23 ` Warner Losh @ 2023-01-22 22:10 ` ron minnich 2023-01-23 7:30 ` arnold 2023-01-29 18:51 ` Warner Losh 2 siblings, 0 replies; 69+ messages in thread From: ron minnich @ 2023-01-22 22:10 UTC (permalink / raw) To: Warner Losh; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1903 bytes --] Thanks very much for this interesting archaeological dig. On Sun, Jan 22, 2023, 4:23 PM Warner Losh <imp@bsdimp.com> wrote: > > > On Sat, Jan 21, 2023 at 11:37 AM Warner Losh <imp@bsdimp.com> wrote: > >> >> Yea. Like many things, there was a transition... the most important bit >> is the shell. And that was more tricky to read through with the phone at >> breakfast... >> > > OK. I've dug a bit further and Clem and I have chatted... Here's the > summary. > > We don't have V4's shell, alas, since all we have from that time period is > the C kernel a few months before the 4th edition release. V5 /bin/sh closes > fd2 and then dups fd1 to fd2. This creates fd2 as something special. V6 > closes all FD's larger than 1 (2-15) and then does the dup(1) which it > makes sure returns 2 or it closes the file. While there were features in V6 > to allow use of fd2/stderr, few programs used then. > > And neither crypt nor passwd reads from fd2. crypt reads from fd0, while > passwd doesn't read. It just replaces the hashed password with the new > password. I've also looked at pr because > > >I do remember that pr -p actually read from FD 2. It probably still does. > > and that's not true in V7 at least... pr didn't have a 'p' arg :). Maybe > later programs started to do these things, but most of what went on with V7 > was a transition to most error messages on stderr, which typically went to > stdout in V6. > > So, people remembering it coming in with V7 are right, in the sense it was > the first release to do it consistently. And the people remembering V4 or > V5 are also right, in a different sense because the shell was ensuring fd2 > was a copy of fd1 there, which a couple of programs (diff) used for errors. > And I believe that the impetus for the V7 changes was phototypesetting > 'file not found' too often... But that last bit is mostly because I want > to believe. > > Warner > [-- Attachment #2: Type: text/html, Size: 2777 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-22 21:23 ` Warner Losh 2023-01-22 22:10 ` ron minnich @ 2023-01-23 7:30 ` arnold 2023-01-23 8:32 ` James Johnston 2023-01-29 18:51 ` Warner Losh 2 siblings, 1 reply; 69+ messages in thread From: arnold @ 2023-01-23 7:30 UTC (permalink / raw) To: imp, clemc; +Cc: tuhs Warner Losh <imp@bsdimp.com> wrote: > And I believe that the impetus for the V7 changes was phototypesetting > 'file not found' too often... But that last bit is mostly because I want > to believe. Doug McIlroy has told that story here, search the archives. It was indeed becase of the phototypesetter. Arnold ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-23 7:30 ` arnold @ 2023-01-23 8:32 ` James Johnston 2023-01-23 8:58 ` G. Branden Robinson 2023-01-23 16:59 ` Douglas McIlroy 0 siblings, 2 replies; 69+ messages in thread From: James Johnston @ 2023-01-23 8:32 UTC (permalink / raw) To: arnold; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 496 bytes --] At one point it was like $22/page. On Sun, Jan 22, 2023 at 11:30 PM <arnold@skeeve.com> wrote: > Warner Losh <imp@bsdimp.com> wrote: > > > And I believe that the impetus for the V7 changes was phototypesetting > > 'file not found' too often... But that last bit is mostly because I want > > to believe. > > Doug McIlroy has told that story here, search the archives. > It was indeed becase of the phototypesetter. > > Arnold > -- James D. (jj) Johnston Chief Scientist, Immersion Networks [-- Attachment #2: Type: text/html, Size: 1009 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-23 8:32 ` James Johnston @ 2023-01-23 8:58 ` G. Branden Robinson 2023-01-23 11:49 ` Brantley Coile 2023-01-23 16:59 ` Douglas McIlroy 1 sibling, 1 reply; 69+ messages in thread From: G. Branden Robinson @ 2023-01-23 8:58 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 1786 bytes --] At 2023-01-23T00:32:53-0800, James Johnston wrote: > At one point it was like $22/page. > > On Sun, Jan 22, 2023 at 11:30 PM <arnold@skeeve.com> wrote: > > > Warner Losh <imp@bsdimp.com> wrote: > > > > > And I believe that the impetus for the V7 changes was > > > phototypesetting 'file not found' too often... But that last bit > > > is mostly because I want to believe. > > > > Doug McIlroy has told that story here, search the archives. > > It was indeed becase of the phototypesetter. Steve Johnson's email[0] (which I cited in my earlier reply to this thread) said it took only "a couple of days" after acquistion of the phototypesetter for this to happen. But the C/A/T was acquired by 1973[1], and the Hunt Brothers' cornering of the silver market occurred in March 1980[2], over a year _after_ the release of V7[3]. It seems both of these can't be true. I wondered if maybe only a later typesetter used a silver-based photochemical development process, but that doesn't work with troff history either, as device-independent troff wasn't ready to go until about January 1981, targetting the C/A/T and the Autologic APS-5[4], the latter with support so fresh that it wasn't in the manual yet[5]. Can someone reconcile these points? Regards, Branden [0] https://minnie.tuhs.org/pipermail/tuhs/2013-December/006113.html [1] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/man/man1/troff.1 [2] https://en.wikipedia.org/wiki/Silver_Thursday [3] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7 [4] https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/00_Annotated_Table_of_Contents.pdf (p. 2) [5] https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/C.1.2_NROFF_TROFF_Users_Manual.pdf (p. 34) [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-23 8:58 ` G. Branden Robinson @ 2023-01-23 11:49 ` Brantley Coile 2023-01-23 14:25 ` Ronald Natalie 0 siblings, 1 reply; 69+ messages in thread From: Brantley Coile @ 2023-01-23 11:49 UTC (permalink / raw) To: G. Branden Robinson; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 2004 bytes --] Original troff targeted only the C/A/T typesetter. bwc > On Jan 23, 2023, at 3:58 AM, G. Branden Robinson <g.branden.robinson@gmail.com> wrote: > > At 2023-01-23T00:32:53-0800, James Johnston wrote: >> At one point it was like $22/page. >> >>> On Sun, Jan 22, 2023 at 11:30 PM <arnold@skeeve.com> wrote: >>> >>> Warner Losh <imp@bsdimp.com> wrote: >>> >>>> And I believe that the impetus for the V7 changes was >>>> phototypesetting 'file not found' too often... But that last bit >>>> is mostly because I want to believe. >>> >>> Doug McIlroy has told that story here, search the archives. >>> It was indeed becase of the phototypesetter. > > Steve Johnson's email[0] (which I cited in my earlier reply to this > thread) said it took only "a couple of days" after acquistion of the > phototypesetter for this to happen. But the C/A/T was acquired by > 1973[1], and the Hunt Brothers' cornering of the silver market occurred > in March 1980[2], over a year _after_ the release of V7[3]. > > It seems both of these can't be true. I wondered if maybe only a later > typesetter used a silver-based photochemical development process, but > that doesn't work with troff history either, as device-independent troff > wasn't ready to go until about January 1981, targetting the C/A/T and > the Autologic APS-5[4], the latter with support so fresh that it wasn't > in the manual yet[5]. > > Can someone reconcile these points? > > Regards, > Branden > > [0] https://minnie.tuhs.org/pipermail/tuhs/2013-December/006113.html > [1] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/man/man1/troff.1 > [2] https://en.wikipedia.org/wiki/Silver_Thursday > [3] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7 > [4] https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/00_Annotated_Table_of_Contents.pdf > (p. 2) > [5] https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/C.1.2_NROFF_TROFF_Users_Manual.pdf > (p. 34) [-- Attachment #2: signature.asc --] [-- Type: application/octet-stream, Size: 833 bytes --] -----BEGIN PGP SIGNATURE----- iQIyBAABCAAdFiEEh3PWHWjjDgcrENwa0Z6cfXEmbc4FAmPOTDEACgkQ0Z6cfXEm bc7Svg/4/AS/2TEBEZXTkITFr91+ZE2BBR757MQ1IQT5ZlAtLM5kZBGA7Ba6D3Zc IJiwORybz7K7cKy/l5Y+fQGTZP5YWyVMhHIS9QE2DsNKDCplg9GwPRt0aV6/RR9O SU6xH5DaWGJPhtIuBZy3GpBLWL/394RZdCB0vTw75dCaq3KnCQEc7ECCN9dM4FA5 N7lb9hAQz3XPthpL145TBBlL6bGny9D1BcZqXnrP0MYS4XKTDSD/iTisdp78GAbm VD4Cy1zLmQFSLSUprD1Y5enZyfPGoNDDAPl4meTDJZX83jfgHBcTL5w0qfQ9QZoV Ir7wMkSU5T0EBQ3RLe9mgIU7DbWsgypI/nZoKvBBOM1srbPfnwAn71cfmQeClSxn F9ngP2Vkj66/kQoqoNhb+ACf4WlXCRAVywjXKvR/owgp2nDMm/KxpqLu9fq+9T8G BwUN7B8baIJG6/cXmNctUCllu0CtzDCNelrEzTrGz/8g8Ra9VLJZQHlh6XfW07Ca m5ba/CctjzcHYLj2m2rPmcWyU52rJEDFSOtkz+rrjGQ1pciXy6OMsKk7gg7kAFwa HGwlJNHY4oqwstkuyisqcqX07wXmaBF9sjEJJ/bPYQIGQkDcn/xtLjLdHOYw7mwC CiUbPX4bqjQVty5UztVBe4TYfIX5FhNr6gntc4nHfEeumeVQtg== =1HzR -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-23 11:49 ` Brantley Coile @ 2023-01-23 14:25 ` Ronald Natalie 2023-01-23 17:43 ` Brantley Coile 0 siblings, 1 reply; 69+ messages in thread From: Ronald Natalie @ 2023-01-23 14:25 UTC (permalink / raw) To: tuhs Indeed but the output format was not too hard to decipher and we wrote drivers for other things. One of the most odd projects I helped with was a program called verset which was a C/A/T type setter emulator that output to a Versetec printer plotter. This was my friend George Toth’s baby. What he did was go down to the NRL and get a complete printout of the typefaces on their C/A/T printed on film at about 72pt. He then cut them into individual pieces. He build a flying spot scanner out of an oscilliscoe with a photomultiplier tube in a scope camera housing. Now in the building next to ours was at the time the worlds finest Scanning Transmission Electron Microscope. It was driven by a PDP-11/20. Esentially the beam scanned back and forth and there was a detected at the bottom. So George, would take the drive and sense wires off the microscope and connect them to the oscilloscope/camera combination. He’d take one letter and stick it to the face of the oscilliscope. We would then bring up the microscope software and tell it to scan a sample. It would do so loading the image into the framebuffer. We would then boot up MiniUnix and read the data out of the framebuffer and store it on an RK05 pack that we’d later take over to our main machine, the PDP-11/45 running a full up (hacked V6) UNIX. It was probably the worlds most expensive text scanner in the world. Of course, I did some favors for that department, so I got free access to that machine when it wasn’t being used by actual microscope operators. ------ Original Message ------ From "Brantley Coile" <brantley@coraid.com> To "G. Branden Robinson" <g.branden.robinson@gmail.com> Cc tuhs@tuhs.org Date 1/23/2023 6:49:03 AM Subject [TUHS] Re: FD 2 >Original troff targeted only the C/A/T typesetter. >bwc > ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-23 14:25 ` Ronald Natalie @ 2023-01-23 17:43 ` Brantley Coile 0 siblings, 0 replies; 69+ messages in thread From: Brantley Coile @ 2023-01-23 17:43 UTC (permalink / raw) To: Ronald Natalie, tuhs What a great story! On January 23, 2023 9:25:25 AM EST, Ronald Natalie <ron@ronnatalie.com> wrote: >Indeed but the output format was not too hard to decipher and we wrote drivers for other things. > >One of the most odd projects I helped with was a program called verset which was a C/A/T type setter emulator that output to a Versetec printer plotter. >This was my friend George Toth’s baby. What he did was go down to the NRL and get a complete printout of the typefaces on their C/A/T printed on film at about 72pt. >He then cut them into individual pieces. He build a flying spot scanner out of an oscilliscoe with a photomultiplier tube in a scope camera housing. > >Now in the building next to ours was at the time the worlds finest Scanning Transmission Electron Microscope. It was driven by a PDP-11/20. Esentially the beam scanned back and forth and there was a detected at the bottom. So George, would take the drive and sense wires off the microscope and connect them to the oscilloscope/camera combination. He’d take one letter and stick it to the face of the oscilliscope. We would then bring up the microscope software and tell it to scan a sample. It would do so loading the image into the framebuffer. We would then boot up MiniUnix and read the data out of the framebuffer and store it on an RK05 pack that we’d later take over to our main machine, the PDP-11/45 running a full up (hacked V6) UNIX. > >It was probably the worlds most expensive text scanner in the world. Of course, I did some favors for that department, so I got free access to that machine when it wasn’t being used by actual microscope operators. > >------ Original Message ------ >From "Brantley Coile" <brantley@coraid.com> >To "G. Branden Robinson" <g.branden.robinson@gmail.com> >Cc tuhs@tuhs.org >Date 1/23/2023 6:49:03 AM >Subject [TUHS] Re: FD 2 > >> Original troff targeted only the C/A/T typesetter. >> bwc >> > ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-23 8:32 ` James Johnston 2023-01-23 8:58 ` G. Branden Robinson @ 2023-01-23 16:59 ` Douglas McIlroy 2023-01-24 7:21 ` arnold 1 sibling, 1 reply; 69+ messages in thread From: Douglas McIlroy @ 2023-01-23 16:59 UTC (permalink / raw) To: James Johnston, TUHS main list >> And I believe that the impetus for the V7 changes was phototypesetting >> 'file not found' too often... But that last bit is mostly because I want >> to believe. > Doug McIlroy has told that story here, search the archives. > It was indeed becase of the phototypesetter. If I ever said that I must have been smoking something at the time. The phototypesetter is a dramatic example, but a minor cause. The major cause was pipes. Downstream programs fail when they receive diagnostics rather than data. And users never see the reason why. Doug On Mon, Jan 23, 2023 at 3:34 AM James Johnston <audioskeptic@gmail.com> wrote: > > At one point it was like $22/page. > > On Sun, Jan 22, 2023 at 11:30 PM <arnold@skeeve.com> wrote: >> >> Warner Losh <imp@bsdimp.com> wrote: >> >> > And I believe that the impetus for the V7 changes was phototypesetting >> > 'file not found' too often... But that last bit is mostly because I want >> > to believe. >> >> Doug McIlroy has told that story here, search the archives. >> It was indeed becase of the phototypesetter. >> >> Arnold > > > > -- > James D. (jj) Johnston > > Chief Scientist, Immersion Networks ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-23 16:59 ` Douglas McIlroy @ 2023-01-24 7:21 ` arnold 0 siblings, 0 replies; 69+ messages in thread From: arnold @ 2023-01-24 7:21 UTC (permalink / raw) To: tuhs, douglas.mcilroy, audioskeptic I stand corrected. Thanks. Arnold Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote: > >> And I believe that the impetus for the V7 changes was phototypesetting > >> 'file not found' too often... But that last bit is mostly because I want > >> to believe. > > > Doug McIlroy has told that story here, search the archives. > > It was indeed becase of the phototypesetter. > > If I ever said that I must have been smoking something at the time. > The phototypesetter is a dramatic example, but a minor cause. > The major cause was pipes. Downstream programs fail > when they receive diagnostics rather than data. And users > never see the reason why. > > Doug > > On Mon, Jan 23, 2023 at 3:34 AM James Johnston <audioskeptic@gmail.com> wrote: > > > > At one point it was like $22/page. > > > > On Sun, Jan 22, 2023 at 11:30 PM <arnold@skeeve.com> wrote: > >> > >> Warner Losh <imp@bsdimp.com> wrote: > >> > >> > And I believe that the impetus for the V7 changes was phototypesetting > >> > 'file not found' too often... But that last bit is mostly because I want > >> > to believe. > >> > >> Doug McIlroy has told that story here, search the archives. > >> It was indeed becase of the phototypesetter. > >> > >> Arnold > > > > > > > > -- > > James D. (jj) Johnston > > > > Chief Scientist, Immersion Networks ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-22 21:23 ` Warner Losh 2023-01-22 22:10 ` ron minnich 2023-01-23 7:30 ` arnold @ 2023-01-29 18:51 ` Warner Losh 2023-01-29 19:20 ` Ron Natalie 2 siblings, 1 reply; 69+ messages in thread From: Warner Losh @ 2023-01-29 18:51 UTC (permalink / raw) To: Clem Cole; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 2762 bytes --] On Sun, Jan 22, 2023 at 2:23 PM Warner Losh <imp@bsdimp.com> wrote: > > > On Sat, Jan 21, 2023 at 11:37 AM Warner Losh <imp@bsdimp.com> wrote: > >> >> Yea. Like many things, there was a transition... the most important bit >> is the shell. And that was more tricky to read through with the phone at >> breakfast... >> > > OK. I've dug a bit further and Clem and I have chatted... Here's the > summary. > > We don't have V4's shell, alas, since all we have from that time period is > the C kernel a few months before the 4th edition release. V5 /bin/sh closes > fd2 and then dups fd1 to fd2. This creates fd2 as something special. V6 > closes all FD's larger than 1 (2-15) and then does the dup(1) which it > makes sure returns 2 or it closes the file. While there were features in V6 > to allow use of fd2/stderr, few programs used then. > > And neither crypt nor passwd reads from fd2. crypt reads from fd0, while > passwd doesn't read. It just replaces the hashed password with the new > password. I've also looked at pr because > > >I do remember that pr -p actually read from FD 2. It probably still does. > > and that's not true in V7 at least... pr didn't have a 'p' arg :). Maybe > later programs started to do these things, but most of what went on with V7 > was a transition to most error messages on stderr, which typically went to > stdout in V6. > > So, people remembering it coming in with V7 are right, in the sense it was > the first release to do it consistently. And the people remembering V4 or > V5 are also right, in a different sense because the shell was ensuring fd2 > was a copy of fd1 there, which a couple of programs (diff) used for errors. > And I believe that the impetus for the V7 changes was phototypesetting > 'file not found' too often... But that last bit is mostly because I want > to believe. > One last historical footnote. In researching a forthcoming article for the 30th anniversary of FreeBSD, I noticed the following: https://www.bell-labs.com/usr/dmr/www/hist.pdf contains Dennis Ritchie's history of the early days of Unix. It was first published in 1979 (so right around the time V7 was being finalized), and revised/reprinted in the famous AT&T Bell Laboratories Technical Journal 63 No. 6 Part 2, October 1984 issue. He talks about FD 0 and FD 1 being special in the pdp-7 implementation on page 4: "The main loop of the shell went as follows: 1) The shell closed all its open files, then opened the terminal special file for standard input and output (file descriptors 0 and 1). ..." No mention is made of when fd 2 became standard error in this paper, which does mention a lot of other unix milestones (hierarchical notation for directories, fork/exec changes, pipes, etc), but not this one. > Warner > [-- Attachment #2: Type: text/html, Size: 3998 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-29 18:51 ` Warner Losh @ 2023-01-29 19:20 ` Ron Natalie 2023-01-29 20:25 ` Warner Losh 2023-01-30 0:25 ` Phil Budne 0 siblings, 2 replies; 69+ messages in thread From: Ron Natalie @ 2023-01-29 19:20 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 755 bytes --] >"The main loop of the shell went as follows: >1) The shell closed all its open files, then opened the terminal >special file for standard input and output (file descriptors 0 and 1). > Unfortunately, the source code says otherwise. None of shells V6, PWB, V7 do anything like is mentioned above. They assume 0 and 1 (and 2) are already open. The only fd redirection they do is when you do pipes or redirection on the command line. Where this is done is, as I posted earlier, in /etc/init. Init opens the tty device and dups it to 1 and then invokes either the shell (if we're in single user mode) or getty for interactive mode. This was done in V6 and PWB (1). In V7, init added a second dup for file descriptor 2. > [-- Attachment #2: Type: text/html, Size: 2500 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-29 19:20 ` Ron Natalie @ 2023-01-29 20:25 ` Warner Losh 2023-01-30 7:50 ` arnold 2023-01-30 0:25 ` Phil Budne 1 sibling, 1 reply; 69+ messages in thread From: Warner Losh @ 2023-01-29 20:25 UTC (permalink / raw) To: Ron Natalie; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1144 bytes --] On Sun, Jan 29, 2023, 12:21 PM Ron Natalie <ron@ronnatalie.com> wrote: > > > > "The main loop of the shell went as follows: > 1) The shell closed all its open files, then opened the terminal special > file for standard input and output (file descriptors 0 and 1). > > Unfortunately, the source code says otherwise. None of shells V6, PWB, > V7 do anything like is mentioned above. They assume 0 and 1 (and 2) are > already open. > The only fd redirection they do is when you do pipes or redirection on the > command line. > This was in reference to the pdp-7 unix implementation. I didn't check the pdp7 version though. So what you said is true about the later versions for sure, starting with v5. Where this is done is, as I posted earlier, in /etc/init. Init opens the > tty device and dups it to 1 and then invokes either the shell (if we're in > single user mode) or getty for interactive mode. > This was done in V6 and PWB (1). In V7, init added a second dup for file > descriptor 2. > Yes. I quite enjoyed that. My surprise was Dennis' paper didn't mention the innovation since it was otherwise quote detailed. Warner > [-- Attachment #2: Type: text/html, Size: 3255 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-29 20:25 ` Warner Losh @ 2023-01-30 7:50 ` arnold 2023-01-30 8:09 ` Rob Pike 2023-01-30 13:26 ` John Cowan 0 siblings, 2 replies; 69+ messages in thread From: arnold @ 2023-01-30 7:50 UTC (permalink / raw) To: ron, imp; +Cc: tuhs > > Where this is done is, as I posted earlier, in /etc/init. Init opens the > > tty device and dups it to 1 and then invokes either the shell (if we're in > > single user mode) or getty for interactive mode. > > This was done in V6 and PWB (1). In V7, init added a second dup for file > > descriptor 2. What I really like is how in V8 - V10 /dev/tty was a (sym)link to /dev/fd/3, and init simply did one more dup call. That eliminated the special tty device driver and was a lovely generalization / simplification. It's too bad this was never picked in the commercial Unixes or in Linux. Arnold ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 7:50 ` arnold @ 2023-01-30 8:09 ` Rob Pike 2023-01-30 15:02 ` Larry McVoy 2023-01-30 13:26 ` John Cowan 1 sibling, 1 reply; 69+ messages in thread From: Rob Pike @ 2023-01-30 8:09 UTC (permalink / raw) To: arnold; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 928 bytes --] In Plan 9 we made /dev/tty (there called /dev/cons) fully virtual, a fiction that provided the semantics. I agree that it's a pity the /dev/tty kludge persists as a kernel hack. And then we have pttys, speaking of pitys. -rob On Mon, Jan 30, 2023 at 6:50 PM <arnold@skeeve.com> wrote: > > > Where this is done is, as I posted earlier, in /etc/init. Init > opens the > > > tty device and dups it to 1 and then invokes either the shell (if > we're in > > > single user mode) or getty for interactive mode. > > > This was done in V6 and PWB (1). In V7, init added a second dup for > file > > > descriptor 2. > > What I really like is how in V8 - V10 /dev/tty was a (sym)link to > /dev/fd/3, > and init simply did one more dup call. That eliminated the special tty > device > driver and was a lovely generalization / simplification. It's too bad this > was never picked in the commercial Unixes or in Linux. > > Arnold > [-- Attachment #2: Type: text/html, Size: 1705 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 8:09 ` Rob Pike @ 2023-01-30 15:02 ` Larry McVoy 2023-01-30 15:16 ` Dan Cross 0 siblings, 1 reply; 69+ messages in thread From: Larry McVoy @ 2023-01-30 15:02 UTC (permalink / raw) To: Rob Pike; +Cc: tuhs On Mon, Jan 30, 2023 at 07:09:55PM +1100, Rob Pike wrote: > And then we have pttys, speaking of pitys. I'm not seeing how you do stuff like ssh into a remote system and have job control, etc, work without some sort of tty. ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 15:02 ` Larry McVoy @ 2023-01-30 15:16 ` Dan Cross 2023-01-30 15:27 ` Larry McVoy 2023-01-30 16:03 ` Bakul Shah 0 siblings, 2 replies; 69+ messages in thread From: Dan Cross @ 2023-01-30 15:16 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs On Mon, Jan 30, 2023 at 10:02 AM Larry McVoy <lm@mcvoy.com> wrote: > On Mon, Jan 30, 2023 at 07:09:55PM +1100, Rob Pike wrote: > > And then we have pttys, speaking of pitys. > > I'm not seeing how you do stuff like ssh into a remote system and have > job control, etc, work without some sort of tty. You don't. But perhaps that model isn't super great. There was no job control on plan9 and I can't say I ever missed it. If I needed another terminal, I just swept open another window. Job control, even remote access a la SSH (or telnet, or rlogin), are a bit of an historical accident. If, instead, my computing environment is the set of shared resources I've imported into my system, then I don't necessarily need something like that. The plan9 `cpu` command, for access to a remote CPU server, conceptually brought the CPU server to you, not the other way around. It was a very different model. - Dan C. ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 15:16 ` Dan Cross @ 2023-01-30 15:27 ` Larry McVoy 2023-01-30 15:35 ` Dan Cross 2023-01-30 16:03 ` Bakul Shah 1 sibling, 1 reply; 69+ messages in thread From: Larry McVoy @ 2023-01-30 15:27 UTC (permalink / raw) To: Dan Cross; +Cc: tuhs On Mon, Jan 30, 2023 at 10:16:25AM -0500, Dan Cross wrote: > On Mon, Jan 30, 2023 at 10:02 AM Larry McVoy <lm@mcvoy.com> wrote: > > On Mon, Jan 30, 2023 at 07:09:55PM +1100, Rob Pike wrote: > > > And then we have pttys, speaking of pitys. > > > > I'm not seeing how you do stuff like ssh into a remote system and have > > job control, etc, work without some sort of tty. > > You don't. But perhaps that model isn't super great. > > There was no job control on plan9 and I can't say I ever missed it. If > I needed another terminal, I just swept open another window. Job > control, even remote access a la SSH (or telnet, or rlogin), are a bit > of an historical accident. If, instead, my computing environment is > the set of shared resources I've imported into my system, then I don't > necessarily need something like that. The plan9 `cpu` command, for > access to a remote CPU server, conceptually brought the CPU server to > you, not the other way around. > > It was a very different model. $ vi foo.c hack, hack ^Z $ make test test test, broken $ fg Yes, I could do that in 2 different terminals but that mode of working is extremely useful, works when I don't have a windowing system, I'm on the console. Not having that model is a deal breaker for me, and I suspect a non trivial number of other people. ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 15:27 ` Larry McVoy @ 2023-01-30 15:35 ` Dan Cross 2023-01-30 15:45 ` Larry McVoy 0 siblings, 1 reply; 69+ messages in thread From: Dan Cross @ 2023-01-30 15:35 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs On Mon, Jan 30, 2023 at 10:27 AM Larry McVoy <lm@mcvoy.com> wrote: > On Mon, Jan 30, 2023 at 10:16:25AM -0500, Dan Cross wrote: > > On Mon, Jan 30, 2023 at 10:02 AM Larry McVoy <lm@mcvoy.com> wrote: > > > On Mon, Jan 30, 2023 at 07:09:55PM +1100, Rob Pike wrote: > > > > And then we have pttys, speaking of pitys. > > > > > > I'm not seeing how you do stuff like ssh into a remote system and have > > > job control, etc, work without some sort of tty. > > > > You don't. But perhaps that model isn't super great. > > > > There was no job control on plan9 and I can't say I ever missed it. If > > I needed another terminal, I just swept open another window. Job > > control, even remote access a la SSH (or telnet, or rlogin), are a bit > > of an historical accident. If, instead, my computing environment is > > the set of shared resources I've imported into my system, then I don't > > necessarily need something like that. The plan9 `cpu` command, for > > access to a remote CPU server, conceptually brought the CPU server to > > you, not the other way around. > > > > It was a very different model. > > $ vi foo.c > hack, hack > ^Z > $ make > test test test, broken > $ fg > > Yes, I could do that in 2 different terminals but that mode of working > is extremely useful, works when I don't have a windowing system, I'm > on the console. > > Not having that model is a deal breaker for me, and I suspect a non > trivial number of other people. Yup. That's a way to work, and if you work with Unix, it's a common one. Plan 9 was different, and a lot of people who were familiar with Unix didn't like that, and were not interested in trying out a different way if it meant that they couldn't bring their existing mental models and workflows into the new environment unchanged. There was no `vi` on plan9, either; well, there was, but it was a MIPS emulator, not a text editor. But with the `acme` editor, your active text editor panes and your terminal window were all part of the editor itself: https://www.youtube.com/watch?v=dP1xVpMPn8M At one point it struck me that Plan 9 didn't succeed as a widespread replacement for Unix/Linux because it was bad or incapable, but rather, because people wanted Linux, and not plan9. - Dan C. ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 15:35 ` Dan Cross @ 2023-01-30 15:45 ` Larry McVoy 2023-01-30 16:09 ` Dan Cross 0 siblings, 1 reply; 69+ messages in thread From: Larry McVoy @ 2023-01-30 15:45 UTC (permalink / raw) To: Dan Cross; +Cc: tuhs On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: > Plan 9 was different, and a lot of people who were familiar with Unix > didn't like that, and were not interested in trying out a different > way if it meant that they couldn't bring their existing mental models > and workflows into the new environment unchanged. > > At one point it struck me that Plan 9 didn't succeed as a widespread > replacement for Unix/Linux because it was bad or incapable, but > rather, because people wanted Linux, and not plan9. Many people make that mistake. New stuff instead of extend old stuff. Look at programming languages for instance. We had C, it was pretty simple to understand, but people wanted more stuff. So now we have things like Rust that is pretty much completely different. Could we not have extended C to do what Rust does? Why do we need an entirely different syntax to say the same things? Seems like Plan 9 fell into that trap. When you invalidate all of the existing knowledge that people have, that creates a barrier to entry. As you said, people don't want to give up their mental model when that model works. They'll only give it up when there is at least a factor of 2 improvement that they care about. These days it feels like people are stuck enough that they want a factor of 10. ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 15:45 ` Larry McVoy @ 2023-01-30 16:09 ` Dan Cross 2023-01-30 16:18 ` Larry McVoy ` (3 more replies) 0 siblings, 4 replies; 69+ messages in thread From: Dan Cross @ 2023-01-30 16:09 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy <lm@mcvoy.com> wrote: > On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: > > Plan 9 was different, and a lot of people who were familiar with Unix > > didn't like that, and were not interested in trying out a different > > way if it meant that they couldn't bring their existing mental models > > and workflows into the new environment unchanged. > > > > At one point it struck me that Plan 9 didn't succeed as a widespread > > replacement for Unix/Linux because it was bad or incapable, but > > rather, because people wanted Linux, and not plan9. > > Many people make that mistake. New stuff instead of extend old stuff. Some would argue that's not a mistake. How else do we innovate if we're just incrementally polishing what's come before? Computing now is radically different than when I started, but if I'd listened to my betters back then, it wouldn't have changed all that much. Actually I _did_ listen to my betters, and now I'm sad that I missed out on a lot of exciting things. > Look at programming languages for instance. We had C, it was pretty > simple to understand, but people wanted more stuff. I think C is a language that people _think_ is simple to understand, and perhaps _was_ simple to understand, but is actually remarkably subtle and a _lot_ of people don't actually have a great handle on how it really works anymore. Particularly now, when the compiler people seem to be prizing optimization above all else and so even obvious behavior that's technically "undefined" results in unexpected behavior (e.g., `if (a > 0 && b > 0 && a*b) < 0) overflow(); // signed integer overflow is UB`. Maybe sadly, C hasn't been a portable macro assembler for decades now. > So now we have > things like Rust that is pretty much completely different. Could we > not have extended C to do what Rust does? Why do we need an entirely > different syntax to say the same things? People tried to extend C to do the things that Rust does and it didn't work. > Seems like Plan 9 fell into that trap. When you invalidate all of the > existing knowledge that people have, that creates a barrier to entry. Plan 9, as a research system, was an experiment in doing things differently. As a research system, it was remarkably influential: a lot of the ideas made it into e.g. Linux. Imitation is the most sincere form of flattery. As a production system, people just wanted Linux. There was a time when people wanted to try out new ideas; oh well. > As you said, people don't want to give up their mental model when that > model works. They'll only give it up when there is at least a factor > of 2 improvement that they care about. These days it feels like people > are stuck enough that they want a factor of 10. Yup, that's about right. The mainframe is still going strong, after all! - Dan C. ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 16:09 ` Dan Cross @ 2023-01-30 16:18 ` Larry McVoy 2023-01-30 19:03 ` Dan Cross 2023-01-30 16:21 ` [TUHS] " Steve Nickolas ` (2 subsequent siblings) 3 siblings, 1 reply; 69+ messages in thread From: Larry McVoy @ 2023-01-30 16:18 UTC (permalink / raw) To: Dan Cross; +Cc: tuhs On Mon, Jan 30, 2023 at 11:09:03AM -0500, Dan Cross wrote: > On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy <lm@mcvoy.com> wrote: > > On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: > > > Plan 9 was different, and a lot of people who were familiar with Unix > > > didn't like that, and were not interested in trying out a different > > > way if it meant that they couldn't bring their existing mental models > > > and workflows into the new environment unchanged. > > > > > > At one point it struck me that Plan 9 didn't succeed as a widespread > > > replacement for Unix/Linux because it was bad or incapable, but > > > rather, because people wanted Linux, and not plan9. > > > > Many people make that mistake. New stuff instead of extend old stuff. > > Some would argue that's not a mistake. How else do we innovate if > we're just incrementally polishing what's come before? I didn't say limit yourself to polishing, I said try and not invalidate people's knowledge while innovating. Too many people go down the path of doing things very differently and they rationalize that they have to do it that way to innovate. That's fine but it means it is going to be harder to get people to try your new stuff. The point I'm trying to make is that "different" is a higher barrier, much, much higher, than "extend". People frequently ignore that and that means other people ignore their work. It is what it is, I doubt I'll convice anyone so I'll drop it. ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 16:18 ` Larry McVoy @ 2023-01-30 19:03 ` Dan Cross 2023-01-30 19:12 ` Brantley Coile 2023-01-30 21:24 ` Larry McVoy 0 siblings, 2 replies; 69+ messages in thread From: Dan Cross @ 2023-01-30 19:03 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs On Mon, Jan 30, 2023 at 11:18 AM Larry McVoy <lm@mcvoy.com> wrote: > On Mon, Jan 30, 2023 at 11:09:03AM -0500, Dan Cross wrote: > > On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy <lm@mcvoy.com> wrote: > > > On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: > > > > Plan 9 was different, and a lot of people who were familiar with Unix > > > > didn't like that, and were not interested in trying out a different > > > > way if it meant that they couldn't bring their existing mental models > > > > and workflows into the new environment unchanged. > > > > > > > > At one point it struck me that Plan 9 didn't succeed as a widespread > > > > replacement for Unix/Linux because it was bad or incapable, but > > > > rather, because people wanted Linux, and not plan9. > > > > > > Many people make that mistake. New stuff instead of extend old stuff. > > > > Some would argue that's not a mistake. How else do we innovate if > > we're just incrementally polishing what's come before? > > I didn't say limit yourself to polishing, I said try and not invalidate > people's knowledge while innovating. > > Too many people go down the path of doing things very differently and > they rationalize that they have to do it that way to innovate. That's > fine but it means it is going to be harder to get people to try your > new stuff. > > The point I'm trying to make is that "different" is a higher barrier, > much, much higher, than "extend". People frequently ignore that and > that means other people ignore their work. > > It is what it is, I doubt I'll convice anyone so I'll drop it. Oh, I don't know. I think it's actually kind of important to see _why_ people didn't want to look deeper into plan9 (for example). The system had a lot to offer, but you had to dig a bit to get into it; a lot of folks never got that far. If it was really lack of job control, then that's a shame. - Dan C. ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 19:03 ` Dan Cross @ 2023-01-30 19:12 ` Brantley Coile 2023-01-30 21:24 ` Larry McVoy 1 sibling, 0 replies; 69+ messages in thread From: Brantley Coile @ 2023-01-30 19:12 UTC (permalink / raw) To: Dan Cross; +Cc: tuhs I have my own theory on why Plan 9 never caught on. It was never productized. It was a modern system arriving right at the post modern age emerged so it didn't resonate with the folks who were doing things. It was too early to be recognized as a cloud operating system, which is what it really is. I say "is" because we actually use it and have done so since 1995. We still ship appliances based on it. We do all our development on it. I have dumps on our file server (Ken's) going back to Jun 22, 2004. I can't really know for sure, but I think those are the three reasons: never made a product, modern not post modern, too early for the cloud. Brantley Coile > On Jan 30, 2023, at 2:03 PM, Dan Cross <crossd@gmail.com> wrote: > > On Mon, Jan 30, 2023 at 11:18 AM Larry McVoy <lm@mcvoy.com> wrote: >> On Mon, Jan 30, 2023 at 11:09:03AM -0500, Dan Cross wrote: >>> On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy <lm@mcvoy.com> wrote: >>>> On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: >>>>> Plan 9 was different, and a lot of people who were familiar with Unix >>>>> didn't like that, and were not interested in trying out a different >>>>> way if it meant that they couldn't bring their existing mental models >>>>> and workflows into the new environment unchanged. >>>>> >>>>> At one point it struck me that Plan 9 didn't succeed as a widespread >>>>> replacement for Unix/Linux because it was bad or incapable, but >>>>> rather, because people wanted Linux, and not plan9. >>>> >>>> Many people make that mistake. New stuff instead of extend old stuff. >>> >>> Some would argue that's not a mistake. How else do we innovate if >>> we're just incrementally polishing what's come before? >> >> I didn't say limit yourself to polishing, I said try and not invalidate >> people's knowledge while innovating. >> >> Too many people go down the path of doing things very differently and >> they rationalize that they have to do it that way to innovate. That's >> fine but it means it is going to be harder to get people to try your >> new stuff. >> >> The point I'm trying to make is that "different" is a higher barrier, >> much, much higher, than "extend". People frequently ignore that and >> that means other people ignore their work. >> >> It is what it is, I doubt I'll convice anyone so I'll drop it. > > Oh, I don't know. I think it's actually kind of important to see _why_ > people didn't want to look deeper into plan9 (for example). The system > had a lot to offer, but you had to dig a bit to get into it; a lot of > folks never got that far. If it was really lack of job control, then > that's a shame. > > - Dan C. ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 19:03 ` Dan Cross 2023-01-30 19:12 ` Brantley Coile @ 2023-01-30 21:24 ` Larry McVoy 2023-01-30 22:15 ` Rob Pike 1 sibling, 1 reply; 69+ messages in thread From: Larry McVoy @ 2023-01-30 21:24 UTC (permalink / raw) To: Dan Cross; +Cc: tuhs On Mon, Jan 30, 2023 at 02:03:32PM -0500, Dan Cross wrote: > On Mon, Jan 30, 2023 at 11:18 AM Larry McVoy <lm@mcvoy.com> wrote: > > On Mon, Jan 30, 2023 at 11:09:03AM -0500, Dan Cross wrote: > > > On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy <lm@mcvoy.com> wrote: > > > > On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: > > > > > Plan 9 was different, and a lot of people who were familiar with Unix > > > > > didn't like that, and were not interested in trying out a different > > > > > way if it meant that they couldn't bring their existing mental models > > > > > and workflows into the new environment unchanged. > > > > > > > > > > At one point it struck me that Plan 9 didn't succeed as a widespread > > > > > replacement for Unix/Linux because it was bad or incapable, but > > > > > rather, because people wanted Linux, and not plan9. > > > > > > > > Many people make that mistake. New stuff instead of extend old stuff. > > > > > > Some would argue that's not a mistake. How else do we innovate if > > > we're just incrementally polishing what's come before? > > > > I didn't say limit yourself to polishing, I said try and not invalidate > > people's knowledge while innovating. > > > > Too many people go down the path of doing things very differently and > > they rationalize that they have to do it that way to innovate. That's > > fine but it means it is going to be harder to get people to try your > > new stuff. > > > > The point I'm trying to make is that "different" is a higher barrier, > > much, much higher, than "extend". People frequently ignore that and > > that means other people ignore their work. > > > > It is what it is, I doubt I'll convice anyone so I'll drop it. > > Oh, I don't know. I think it's actually kind of important to see _why_ > people didn't want to look deeper into plan9 (for example). The system > had a lot to offer, but you had to dig a bit to get into it; a lot of > folks never got that far. If it was really lack of job control, then > that's a shame. It's certainly not just job control. I think it's a combo of being unfamiliar, no source (at first I believe) and Linux was already pretty far along. The lesson is that if there is an installed base, and you want people to move, you have to make that easy and there has to be a noticeable gain. Plan 9 sounded cool to me but Linux was easy. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 21:24 ` Larry McVoy @ 2023-01-30 22:15 ` Rob Pike 2023-01-30 22:50 ` ron minnich 2023-01-30 23:05 ` [TUHS] Child of plan9? (Re: " Bakul Shah 0 siblings, 2 replies; 69+ messages in thread From: Rob Pike @ 2023-01-30 22:15 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 3595 bytes --] There was Plan 9 source available, but the early releases were in the AT&T Unix mode and required some payment or academic connection. The early demo disks might not have had source - I don't remember - but if not, there was simply no room on a floppy. The CD releases had full source. Plan 9 was a research system. It was hoped that maybe one day it would become a commercial success, but that was never the prime motivation. It only "failed" as a product, and there are many contributing factors there, including existing systems that were good enough, a desire for people to have "workstations" and ignore the benefits of a completing window UI on a mainframe (Cray was an exception, earlier), and AT&T lawyers refusing to think realistically about open source (about as polite a way I can express a multiyear fight that never ended, only fizzled into stalemate). As a research system, Plan 9 was a huge success. We're still talking about its ideas 30+ years on. -rob On Tue, Jan 31, 2023 at 8:24 AM Larry McVoy <lm@mcvoy.com> wrote: > On Mon, Jan 30, 2023 at 02:03:32PM -0500, Dan Cross wrote: > > On Mon, Jan 30, 2023 at 11:18 AM Larry McVoy <lm@mcvoy.com> wrote: > > > On Mon, Jan 30, 2023 at 11:09:03AM -0500, Dan Cross wrote: > > > > On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy <lm@mcvoy.com> wrote: > > > > > On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: > > > > > > Plan 9 was different, and a lot of people who were familiar with > Unix > > > > > > didn't like that, and were not interested in trying out a > different > > > > > > way if it meant that they couldn't bring their existing mental > models > > > > > > and workflows into the new environment unchanged. > > > > > > > > > > > > At one point it struck me that Plan 9 didn't succeed as a > widespread > > > > > > replacement for Unix/Linux because it was bad or incapable, but > > > > > > rather, because people wanted Linux, and not plan9. > > > > > > > > > > Many people make that mistake. New stuff instead of extend old > stuff. > > > > > > > > Some would argue that's not a mistake. How else do we innovate if > > > > we're just incrementally polishing what's come before? > > > > > > I didn't say limit yourself to polishing, I said try and not invalidate > > > people's knowledge while innovating. > > > > > > Too many people go down the path of doing things very differently and > > > they rationalize that they have to do it that way to innovate. That's > > > fine but it means it is going to be harder to get people to try your > > > new stuff. > > > > > > The point I'm trying to make is that "different" is a higher barrier, > > > much, much higher, than "extend". People frequently ignore that and > > > that means other people ignore their work. > > > > > > It is what it is, I doubt I'll convice anyone so I'll drop it. > > > > Oh, I don't know. I think it's actually kind of important to see _why_ > > people didn't want to look deeper into plan9 (for example). The system > > had a lot to offer, but you had to dig a bit to get into it; a lot of > > folks never got that far. If it was really lack of job control, then > > that's a shame. > > It's certainly not just job control. I think it's a combo of being > unfamiliar, no source (at first I believe) and Linux was already > pretty far along. > > The lesson is that if there is an installed base, and you want people > to move, you have to make that easy and there has to be a noticeable > gain. Plan 9 sounded cool to me but Linux was easy. > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > [-- Attachment #2: Type: text/html, Size: 5218 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 22:15 ` Rob Pike @ 2023-01-30 22:50 ` ron minnich 2023-01-30 23:05 ` [TUHS] Child of plan9? (Re: " Bakul Shah 1 sibling, 0 replies; 69+ messages in thread From: ron minnich @ 2023-01-30 22:50 UTC (permalink / raw) To: Rob Pike; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 4426 bytes --] It's a long list of ideas that came from Plan 9 into Unix. One of those wonderful plan 9 ideas, the cpu command, with all it implies, has new life: github.com/u-root/cpu. Several companies are using the cpu command as the basis of light weight VM and edge environments, for example. Also, rfork went into freebsd ca 1996, and it's still there. Al Viro, IIRC, put some stuff into his VFS ca 1998 that specifically came from plan 9, including private mounts. We used them at LANL to build private name spaces for cluster nodes, over 9p, as part of Clustermatic. Some core ideas of controlling subsystems via writable synthetics also made it in. And on and on. On Mon, Jan 30, 2023 at 2:17 PM Rob Pike <robpike@gmail.com> wrote: > There was Plan 9 source available, but the early releases were in the AT&T > Unix mode and required some payment or academic connection. The early demo > disks might not have had source - I don't remember - but if not, there was > simply no room on a floppy. The CD releases had full source. > > Plan 9 was a research system. It was hoped that maybe one day it would > become a commercial success, but that was never the prime motivation. It > only "failed" as a product, and there are many contributing factors there, > including existing systems that were good enough, a desire for people to > have "workstations" and ignore the benefits of a completing window UI on a > mainframe (Cray was an exception, earlier), and AT&T lawyers refusing to > think realistically about open source (about as polite a way I can express > a multiyear fight that never ended, only fizzled into stalemate). > > As a research system, Plan 9 was a huge success. We're still talking about > its ideas 30+ years on. > > -rob > > > On Tue, Jan 31, 2023 at 8:24 AM Larry McVoy <lm@mcvoy.com> wrote: > >> On Mon, Jan 30, 2023 at 02:03:32PM -0500, Dan Cross wrote: >> > On Mon, Jan 30, 2023 at 11:18 AM Larry McVoy <lm@mcvoy.com> wrote: >> > > On Mon, Jan 30, 2023 at 11:09:03AM -0500, Dan Cross wrote: >> > > > On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy <lm@mcvoy.com> wrote: >> > > > > On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: >> > > > > > Plan 9 was different, and a lot of people who were familiar >> with Unix >> > > > > > didn't like that, and were not interested in trying out a >> different >> > > > > > way if it meant that they couldn't bring their existing mental >> models >> > > > > > and workflows into the new environment unchanged. >> > > > > > >> > > > > > At one point it struck me that Plan 9 didn't succeed as a >> widespread >> > > > > > replacement for Unix/Linux because it was bad or incapable, but >> > > > > > rather, because people wanted Linux, and not plan9. >> > > > > >> > > > > Many people make that mistake. New stuff instead of extend old >> stuff. >> > > > >> > > > Some would argue that's not a mistake. How else do we innovate if >> > > > we're just incrementally polishing what's come before? >> > > >> > > I didn't say limit yourself to polishing, I said try and not >> invalidate >> > > people's knowledge while innovating. >> > > >> > > Too many people go down the path of doing things very differently and >> > > they rationalize that they have to do it that way to innovate. That's >> > > fine but it means it is going to be harder to get people to try your >> > > new stuff. >> > > >> > > The point I'm trying to make is that "different" is a higher barrier, >> > > much, much higher, than "extend". People frequently ignore that and >> > > that means other people ignore their work. >> > > >> > > It is what it is, I doubt I'll convice anyone so I'll drop it. >> > >> > Oh, I don't know. I think it's actually kind of important to see _why_ >> > people didn't want to look deeper into plan9 (for example). The system >> > had a lot to offer, but you had to dig a bit to get into it; a lot of >> > folks never got that far. If it was really lack of job control, then >> > that's a shame. >> >> It's certainly not just job control. I think it's a combo of being >> unfamiliar, no source (at first I believe) and Linux was already >> pretty far along. >> >> The lesson is that if there is an installed base, and you want people >> to move, you have to make that easy and there has to be a noticeable >> gain. Plan 9 sounded cool to me but Linux was easy. >> -- >> --- >> Larry McVoy Retired to fishing >> http://www.mcvoy.com/lm/boat >> > [-- Attachment #2: Type: text/html, Size: 6403 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Child of plan9? (Re: FD 2 2023-01-30 22:15 ` Rob Pike 2023-01-30 22:50 ` ron minnich @ 2023-01-30 23:05 ` Bakul Shah 2023-01-31 3:19 ` [TUHS] " Andrew Warkentin 1 sibling, 1 reply; 69+ messages in thread From: Bakul Shah @ 2023-01-30 23:05 UTC (permalink / raw) To: The Eunuchs Hysterical Society This wish is perhaps shared by no one else but I'd still love to have a system where the kernel has the clean architectural lines of plan9 + more good stuff from it, and a Unixy API for many existing programs, perhaps as a shared lib. And I don't want all the heft of BSD or Linux kernels! Now this may be quite impractical (like trying to make C as safe as Rust) but that is what I want! I just think there is a lot more here that can be explored further. > On Jan 30, 2023, at 2:15 PM, Rob Pike <robpike@gmail.com> wrote: > > There was Plan 9 source available, but the early releases were in the AT&T Unix mode and required some payment or academic connection. The early demo disks might not have had source - I don't remember - but if not, there was simply no room on a floppy. The CD releases had full source. > > Plan 9 was a research system. It was hoped that maybe one day it would become a commercial success, but that was never the prime motivation. It only "failed" as a product, and there are many contributing factors there, including existing systems that were good enough, a desire for people to have "workstations" and ignore the benefits of a completing window UI on a mainframe (Cray was an exception, earlier), and AT&T lawyers refusing to think realistically about open source (about as polite a way I can express a multiyear fight that never ended, only fizzled into stalemate). > > As a research system, Plan 9 was a huge success. We're still talking about its ideas 30+ years on. > > -rob > > > On Tue, Jan 31, 2023 at 8:24 AM Larry McVoy <lm@mcvoy.com> wrote: > On Mon, Jan 30, 2023 at 02:03:32PM -0500, Dan Cross wrote: > > On Mon, Jan 30, 2023 at 11:18 AM Larry McVoy <lm@mcvoy.com> wrote: > > > On Mon, Jan 30, 2023 at 11:09:03AM -0500, Dan Cross wrote: > > > > On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy <lm@mcvoy.com> wrote: > > > > > On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: > > > > > > Plan 9 was different, and a lot of people who were familiar with Unix > > > > > > didn't like that, and were not interested in trying out a different > > > > > > way if it meant that they couldn't bring their existing mental models > > > > > > and workflows into the new environment unchanged. > > > > > > > > > > > > At one point it struck me that Plan 9 didn't succeed as a widespread > > > > > > replacement for Unix/Linux because it was bad or incapable, but > > > > > > rather, because people wanted Linux, and not plan9. > > > > > > > > > > Many people make that mistake. New stuff instead of extend old stuff. > > > > > > > > Some would argue that's not a mistake. How else do we innovate if > > > > we're just incrementally polishing what's come before? > > > > > > I didn't say limit yourself to polishing, I said try and not invalidate > > > people's knowledge while innovating. > > > > > > Too many people go down the path of doing things very differently and > > > they rationalize that they have to do it that way to innovate. That's > > > fine but it means it is going to be harder to get people to try your > > > new stuff. > > > > > > The point I'm trying to make is that "different" is a higher barrier, > > > much, much higher, than "extend". People frequently ignore that and > > > that means other people ignore their work. > > > > > > It is what it is, I doubt I'll convice anyone so I'll drop it. > > > > Oh, I don't know. I think it's actually kind of important to see _why_ > > people didn't want to look deeper into plan9 (for example). The system > > had a lot to offer, but you had to dig a bit to get into it; a lot of > > folks never got that far. If it was really lack of job control, then > > that's a shame. > > It's certainly not just job control. I think it's a combo of being > unfamiliar, no source (at first I believe) and Linux was already > pretty far along. > > The lesson is that if there is an installed base, and you want people > to move, you have to make that easy and there has to be a noticeable > gain. Plan 9 sounded cool to me but Linux was easy. > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: Child of plan9? (Re: FD 2 2023-01-30 23:05 ` [TUHS] Child of plan9? (Re: " Bakul Shah @ 2023-01-31 3:19 ` Andrew Warkentin 0 siblings, 0 replies; 69+ messages in thread From: Andrew Warkentin @ 2023-01-31 3:19 UTC (permalink / raw) To: tuhs On 1/30/23, Bakul Shah <bakul@iitbombay.org> wrote: > This wish is perhaps shared by no one else but I'd still love to have a > system where the kernel has the clean > architectural lines of plan9 + more good stuff from it, and a Unixy API for > many existing programs, perhaps as a shared lib. And I don't want all the > heft of BSD or Linux kernels! > > Now this may be quite impractical (like trying to make C as safe as Rust) > but that is what I want! I just think there is a lot more here that can be > explored further. > I'm writing something sort of like that. Specifically it will be a QNX-like OS in which literally everything is a file (even all process state and memory), with pretty much the only real primitives being variants of read()/write(), and everything else will be built on top of those (even other file APIs like open()/close()/stat()). The user-level API will be mostly compatible with conventional Unix, but will be split into multiple libraries rather than throwing everything in libc (there will be a base system library implementing the core file API, and libc and a few other libraries implementing a relatively standard Unix API will sit on top of this). ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 16:09 ` Dan Cross 2023-01-30 16:18 ` Larry McVoy @ 2023-01-30 16:21 ` Steve Nickolas 2023-01-30 16:27 ` Larry McVoy 2023-01-31 21:27 ` Dave Horsfall 2023-01-30 16:48 ` Theodore Ts'o 2023-01-30 16:57 ` Andy Kosela 3 siblings, 2 replies; 69+ messages in thread From: Steve Nickolas @ 2023-01-30 16:21 UTC (permalink / raw) To: tuhs On Mon, 30 Jan 2023, Dan Cross wrote: > I think C is a language that people _think_ is simple to understand, > and perhaps _was_ simple to understand, but is actually remarkably > subtle and a _lot_ of people don't actually have a great handle on how > it really works anymore. Particularly now, when the compiler people > seem to be prizing optimization above all else and so even obvious > behavior that's technically "undefined" results in unexpected behavior > (e.g., `if (a > 0 && b > 0 && a*b) < 0) overflow(); // signed integer > overflow is UB`. Maybe sadly, C hasn't been a portable macro assembler > for decades now. I always assume compiler braindeath. Always use parentheses; never assume any specific order of precedence. I've actually been bitten by compilers doing unexpectedly stupid things, so I guard around them. I'll never merge two chars into a short with c=(a<<8)|b; I will ALWAYS do this: c=a; c<<=8; c|=b; because 16-bit MS-DOS compilers will ALWAYS manage to blunder that, though 32-bit compilers get it right (the sane thing to do would be to treat it as a word bitshift, but the compiler treats it as a byteshift because a is uint8_t). I'll never do if (a==b&&c==d), always if ((a==b)&&(c==d)). I always try to assume the compiler will wreck my code in hilariously braindamaged ways and code so precisely that it cannot do so. <snip> > Imitation is the most sincere form of flattery. The actual saying continues "...that mediocrity can make to greatness", which changes the meaning a bit. ;p -uso. ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 16:21 ` [TUHS] " Steve Nickolas @ 2023-01-30 16:27 ` Larry McVoy 2023-01-30 16:32 ` ron minnich ` (2 more replies) 2023-01-31 21:27 ` Dave Horsfall 1 sibling, 3 replies; 69+ messages in thread From: Larry McVoy @ 2023-01-30 16:27 UTC (permalink / raw) To: Steve Nickolas; +Cc: tuhs On Mon, Jan 30, 2023 at 11:21:45AM -0500, Steve Nickolas wrote: > I'll never do if (a==b&&c==d), always if ((a==b)&&(c==d)). I'm a if ((a == b) && (c == d)) guy but yeah, spell it out not just so the compiler doesn't mess with you, for me, it is more so my eyes run over the expression and I can parse it with less brain cells, parens let me think less. I've always had the opinion that code should be written in a way that is the most easy to read. ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 16:27 ` Larry McVoy @ 2023-01-30 16:32 ` ron minnich 2023-01-30 16:40 ` Clem Cole 2023-01-30 19:55 ` Lawrence Stewart 2 siblings, 0 replies; 69+ messages in thread From: ron minnich @ 2023-01-30 16:32 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 724 bytes --] This is no longer about FD2, maybe it's time for a source quench on the thread? I keep expecting new messages on FD2 and somehow we're arguing about C and make again :-) On Mon, Jan 30, 2023 at 8:27 AM Larry McVoy <lm@mcvoy.com> wrote: > On Mon, Jan 30, 2023 at 11:21:45AM -0500, Steve Nickolas wrote: > > I'll never do if (a==b&&c==d), always if ((a==b)&&(c==d)). > > I'm a > > if ((a == b) && (c == d)) > > guy but yeah, spell it out not just so the compiler doesn't mess with > you, for me, it is more so my eyes run over the expression and I can > parse it with less brain cells, parens let me think less. > > I've always had the opinion that code should be written in a way that > is the most easy to read. > [-- Attachment #2: Type: text/html, Size: 1092 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 16:27 ` Larry McVoy 2023-01-30 16:32 ` ron minnich @ 2023-01-30 16:40 ` Clem Cole 2023-01-30 19:55 ` Lawrence Stewart 2 siblings, 0 replies; 69+ messages in thread From: Clem Cole @ 2023-01-30 16:40 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 364 bytes --] On Mon, Jan 30, 2023 at 11:27 AM Larry McVoy <lm@mcvoy.com> wrote: > I've always had the opinion that code should be written in a way that > is the most easy to read. > Amen -- using the principle of '*least obscure*' or obtuse - being obvious is thinking about a quick and casual human reader of code, not a compiler someone taking intense notes. ᐧ [-- Attachment #2: Type: text/html, Size: 1139 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 16:27 ` Larry McVoy 2023-01-30 16:32 ` ron minnich 2023-01-30 16:40 ` Clem Cole @ 2023-01-30 19:55 ` Lawrence Stewart 2 siblings, 0 replies; 69+ messages in thread From: Lawrence Stewart @ 2023-01-30 19:55 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs Ha, when I was doing a design verification stint, I caught a piece of verilog that depended on an incorrect view of order of operations and saved the corp a new mask, so completely agree. Infix notation is just a bad idea. > On Jan 30, 2023, at 11:27 AM, Larry McVoy <lm@mcvoy.com> wrote: > > On Mon, Jan 30, 2023 at 11:21:45AM -0500, Steve Nickolas wrote: >> I'll never do if (a==b&&c==d), always if ((a==b)&&(c==d)). > > I'm a > > if ((a == b) && (c == d)) > > guy but yeah, spell it out not just so the compiler doesn't mess with > you, for me, it is more so my eyes run over the expression and I can > parse it with less brain cells, parens let me think less. > > I've always had the opinion that code should be written in a way that > is the most easy to read. ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 16:21 ` [TUHS] " Steve Nickolas 2023-01-30 16:27 ` Larry McVoy @ 2023-01-31 21:27 ` Dave Horsfall 1 sibling, 0 replies; 69+ messages in thread From: Dave Horsfall @ 2023-01-31 21:27 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Mon, 30 Jan 2023, Steve Nickolas wrote: [...] > I've actually been bitten by compilers doing unexpectedly stupid things, > so I guard around them. I'll never merge two chars into a short with > > c=(a<<8)|b; I used to do just that to disambiguate commands that started with the same letter in a UT-200 driver that I (re)wrote. Of course, I was young and stupid back then... It's quite something to see things like: switch (cmd) { case 'AA': ... break; case 'AB': ... break; default: wtf(); /* no return */ } Horribly machine-dependent, but I knew the 11/40 and Ed 6 quite well. [...] > I'll never do if (a==b&&c==d), always if ((a==b)&&(c==d)). Indeed; I *always* use parentheses even if they are not necessary (for my benefit, at least). -- Dave ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 16:09 ` Dan Cross 2023-01-30 16:18 ` Larry McVoy 2023-01-30 16:21 ` [TUHS] " Steve Nickolas @ 2023-01-30 16:48 ` Theodore Ts'o 2023-01-30 16:57 ` Andy Kosela 3 siblings, 0 replies; 69+ messages in thread From: Theodore Ts'o @ 2023-01-30 16:48 UTC (permalink / raw) To: Dan Cross; +Cc: tuhs On Mon, Jan 30, 2023 at 11:09:03AM -0500, Dan Cross wrote: > > > At one point it struck me that Plan 9 didn't succeed as a widespread > > > replacement for Unix/Linux because it was bad or incapable, but > > > rather, because people wanted Linux, and not plan9. > > > > Many people make that mistake. New stuff instead of extend old stuff. > > Some would argue that's not a mistake. How else do we innovate if > we're just incrementally polishing what's come before? The challenge is how do you extend the most common interfaces so that you don't break the most common workflows and applications, without adding too much backwards compatibility hair, and without stiffling innovation. I think we can err in both directions --- break the world, and no one will adopt the OS, and too much backwars compaibility and it's much, much harder to innovate. The happy medium which Linux uses is that the userspace interfaces should mostly stay compatible ("thou shoult not break userspace") unless there are really, really good reasons (such as security vulnerabilities) when you can't really do that. But internal interfaces, including those that might be used by out of three kernel modules --- it's totally fair game, and if you have academics who have professors who were trained up on the 4.14 kernel, when they were in graduate school --- sorry, your knowledge is out of date, and you can either force your graduae students to use an obsolescent kernel for their research, or you're going to have to get with the times. (I remember in the early days of BSD where people considered it a feature that academic research tools wouldn't be broken; I believe I remember hearing that as excuses not to rework with networking and tty layers, whereas Linux rewrite the networking stack from scratch 2 or 3 times, and we've since completely reworked the block layer to deal with ultra-fast devices, even if that meant that all external device drivers would be broken.) Of course, there will be kvetching no matter where you draw the line, but simply saying, to *hell* with the old ways of doing things, and we can't break anything, even internal interfaces, are both recipes for failure IMHO. > > As you said, people don't want to give up their mental model when that > > model works. They'll only give it up when there is at least a factor > > of 2 improvement that they care about. These days it feels like people > > are stuck enough that they want a factor of 10. > > Yup, that's about right. The mainframe is still going strong, after all! One of the things that we can at $WORK is to be able to translate storage TCO costs (cost per byte, cost per IOPS), cost of CPU utilization, and cost of memory, etc., into SWE-equivalents. So when we propose a new initiative, we'll take the cost to implement the project, as well as the cost to change all of the downstream users in the software/storage stack, and do a cost benefit comparison. For example, we might take the cost to implement the use of some new storage technique, such as Hybrid SMR[1], dd a generous buffer because projects always take longer and cost more than you first might think, and then compare it to the 5 year storage TCO costs, using SWE-equivalents as the common unit of comparison. And the project will only get green-lighted if the benefits exceed the costs by a goodly margin. [1] https://blog.google/products/google-cloud/dynamic-hybrid-smr-ocp-proposal-improve-data-center-disk-drives/ Of course, things are different if you are working in academia, where things like getting published in a venue that will help build you or your associates' tenure case are going to be more important. In any case, if we are going to claim that programming is an engineering discpline, then engineering tradeoffs are important to remember. Companies or departments who forget this lesson are much more likely to get reminded of it when the activist investors start pushing for layoffs, or when you start wonderng why your company had to get sold off to the highest bidder... - Ted ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 16:09 ` Dan Cross ` (2 preceding siblings ...) 2023-01-30 16:48 ` Theodore Ts'o @ 2023-01-30 16:57 ` Andy Kosela 2023-01-30 17:04 ` Warner Losh 3 siblings, 1 reply; 69+ messages in thread From: Andy Kosela @ 2023-01-30 16:57 UTC (permalink / raw) To: Dan Cross; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 3065 bytes --] On Monday, January 30, 2023, Dan Cross <crossd@gmail.com> wrote: > On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy <lm@mcvoy.com> wrote: > > On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: > > > Plan 9 was different, and a lot of people who were familiar with Unix > > > didn't like that, and were not interested in trying out a different > > > way if it meant that they couldn't bring their existing mental models > > > and workflows into the new environment unchanged. > > > > > > At one point it struck me that Plan 9 didn't succeed as a widespread > > > replacement for Unix/Linux because it was bad or incapable, but > > > rather, because people wanted Linux, and not plan9. > > > > Many people make that mistake. New stuff instead of extend old stuff. > > Some would argue that's not a mistake. How else do we innovate if > we're just incrementally polishing what's come before? I would argue that Linux actually did a lot of things differently. It tried to conform to POSIX, but still there were a lof of fresh ideas that actually took off. It was not possible in the free BSD world which inherited much more from the old Unix world. > > So now we have > > things like Rust that is pretty much completely different. Could we > > not have extended C to do what Rust does? Why do we need an entirely > > different syntax to say the same things? > > People tried to extend C to do the things that Rust does and it didn't > work. Smells like C++ to me. Rust in essence is a re-implementation of C++ not C. It tries to pack as much features as it possibly can. I don't know of any other language that throughout the years remained as pure and minimal as C. (maybe Forth). > > > Seems like Plan 9 fell into that trap. When you invalidate all of the > > existing knowledge that people have, that creates a barrier to entry. > > Plan 9, as a research system, was an experiment in doing things > differently. As a research system, it was remarkably influential: a > lot of the ideas made it into e.g. Linux. Imitation is the most > sincere form of flattery. As a production system, people just wanted > Linux. There was a time when people wanted to try out new ideas; oh > well. Linux came out in the right place at the right time, right around the time when the Internet really became a cyberspace spanning the whole globe. Finland was first connected to the Internet in 1989. Linus bought his first 386DX33 in January 1991. To me Linux represented a revolution in computing. It built on the shoulders of Unix forefathers but at the same time was a breath of fresh air in the Unix space. Young people at the time wanted that. That's why it became so wildly popular. It was a completely free, idealistic worldwide movement. It brought together a diverse group of people: university Unix programmers, home computer enthusiasts and demoscene hackers who just recently replaced their 8-bit C64's and Atari's with fresh 386-based PCs, young security hackers who watched too much War Games, etc. It was a very fresh movement at the time. --Andy [-- Attachment #2: Type: text/html, Size: 3893 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 16:57 ` Andy Kosela @ 2023-01-30 17:04 ` Warner Losh 2023-01-30 20:38 ` Theodore Ts'o 0 siblings, 1 reply; 69+ messages in thread From: Warner Losh @ 2023-01-30 17:04 UTC (permalink / raw) To: Andy Kosela; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 2157 bytes --] On Mon, Jan 30, 2023 at 9:59 AM Andy Kosela <akosela@andykosela.com> wrote: > On Monday, January 30, 2023, Dan Cross <crossd@gmail.com> wrote: > >> On Mon, Jan 30, 2023 at 10:45 AM Larry McVoy <lm@mcvoy.com> wrote: >> > On Mon, Jan 30, 2023 at 10:35:25AM -0500, Dan Cross wrote: >> > > Plan 9 was different, and a lot of people who were familiar with Unix >> > > didn't like that, and were not interested in trying out a different >> > > way if it meant that they couldn't bring their existing mental models >> > > and workflows into the new environment unchanged. >> > > >> > > At one point it struck me that Plan 9 didn't succeed as a widespread >> > > replacement for Unix/Linux because it was bad or incapable, but >> > > rather, because people wanted Linux, and not plan9. >> > >> > Many people make that mistake. New stuff instead of extend old stuff. >> >> Some would argue that's not a mistake. How else do we innovate if >> we're just incrementally polishing what's come before? > > > I would argue that Linux actually did a lot of things differently. It > tried to conform to POSIX, but still there were a lof of fresh ideas that > actually took off. > Yes, but one legacy of that was Linux tried to use the System V ABI everywhere with extensions, and that means errno values are different in linux for different platforms, signals are a bit different etc. > It was not possible in the free BSD world which inherited much more from > the old Unix world. > It's been totally possible in the BSD world. The vm systems have been redone in ways that make the original look different, the tty layers are now completely different (something bde couldn't accomplish in the early days), the autoconf / device probing/attaching is different, the fact that removable devices extend well beyond disk packs, SMP support (several different flavors), bus independent dma and device register access, etc. Now granted, in the earliest of days some things seemed too sacrosanct, but all the BSDs quickly learned being too rigid didn't generally have good outcomes (though some corners of the systems have taken longer than others to realize that). Warner [-- Attachment #2: Type: text/html, Size: 3092 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 17:04 ` Warner Losh @ 2023-01-30 20:38 ` Theodore Ts'o 2023-01-30 21:01 ` Warner Losh 2023-01-30 21:10 ` Clem Cole 0 siblings, 2 replies; 69+ messages in thread From: Theodore Ts'o @ 2023-01-30 20:38 UTC (permalink / raw) To: Warner Losh; +Cc: tuhs On Mon, Jan 30, 2023 at 10:04:46AM -0700, Warner Losh wrote: > > Yes, but one legacy of that was Linux tried to use the System V ABI > everywhere with extensions, and that means errno values are different in > linux for different platforms, signals are a bit different etc. Linux used the *Minix* ABI for 32-bit x86, so that Minix 1.x binaries would run on Linux until recently (when a.out support was removed). For some of the first original ports (e.g., Alpha and Sparc) there was an attempt to maintain partial ABI compatibility with OSF/1 and SunOS, mainly so that proprietary binaries (mostly Netscape) could run on those Linux ports. However, for pretty much all of the newer architectures, the system call and signal numbers used are inherited from the x86 and x86_64 syscall and signal numbers. After Netscape passed, the demand for running non-native binaries rapidly declined. What you may be remembering was that Linux used to have an emulation layer for Intel Binary Compatibility Standard (iBCS2)[1]. However, this was not native support; Linux used "int 0x80" for xx86 system call with a.out (and later ELF) binaries, while iBCS2 mandated use of "lcall 7,0" syscalls and COFF binaries. So iBCS2 support was an optional thing that you had to explicitly configure the kernel to support, and while it was quite complete, it was not Linux's native userspace interface. [1] https://www.linux.co.cr/free-unix-os/review/acrobat/940612.pdf Story time: at one point in the early 90's, MIT purchased a site license for a proprietary spreadsheet product for ISC Unix, which we planned to run on Linux systems at MIT using iBCS2. When I contacted Michael Johnson[2], the engineer at that company to implement support for the site license ---- which was going to rely on checking the IP address on the system to see if it was 18.x.y.z --- I found out that Michael built and tested the spreadsheet using Linux with iBCS2 emulation, and only *later* made sure it would actually run on ISC Unix, because Linux was a much more pleasant development environment than the System V alternatives. :-) [2] Michael later was one of the founders of Red Hat. In any case, while in practice some platforms use a unique set of code points for system calls and signal numbers (thos are mostly the older architectures which exist mostly for historic interest), most platforms which run Linux today actually use a consistent set of system call and signal numbers. That being said, we did implement many of the System V extensions, mostly because there was demand from the proprietary software vendors who needed to be convinced to port their applications from Solars, HPUX, AIX, etc., to Linux. Mercifully, Linux never implemented Streams (thank $DEITY Oracle didn't make that a requirement :-) and we did have BSD job control from the earliest days. That happened because in early 1992, I considered Job Control to be a highly important feature that Linux **had** to have, and so I sat down with the POSIX.1 specification, and implemented job control from the spec. The reason why Linux's tty layer has a bit of a System V "flavor" at least from a system call perspective has nothing to do the system call ABI, and more to do with the fact that apparently representatives from System V derivatives seemed to have a dominant role on the POSIX committee. - Ted ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 20:38 ` Theodore Ts'o @ 2023-01-30 21:01 ` Warner Losh 2023-01-30 21:10 ` Clem Cole 1 sibling, 0 replies; 69+ messages in thread From: Warner Losh @ 2023-01-30 21:01 UTC (permalink / raw) To: Theodore Ts'o; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 4919 bytes --] On Mon, Jan 30, 2023 at 1:39 PM Theodore Ts'o <tytso@mit.edu> wrote: > On Mon, Jan 30, 2023 at 10:04:46AM -0700, Warner Losh wrote: > > > > Yes, but one legacy of that was Linux tried to use the System V ABI > > everywhere with extensions, and that means errno values are different in > > linux for different platforms, signals are a bit different etc. > > Linux used the *Minix* ABI for 32-bit x86, so that Minix 1.x binaries > would run on Linux until recently (when a.out support was removed). > For some of the first original ports (e.g., Alpha and Sparc) there was > an attempt to maintain partial ABI compatibility with OSF/1 and SunOS, > mainly so that proprietary binaries (mostly Netscape) could run on > those Linux ports. However, for pretty much all of the newer > architectures, the system call and signal numbers used are inherited > from the x86 and x86_64 syscall and signal numbers. After Netscape > passed, the demand for running non-native binaries rapidly declined. > > What you may be remembering was that Linux used to have an emulation > layer for Intel Binary Compatibility Standard (iBCS2)[1]. However, > this was not native support; Linux used "int 0x80" for xx86 system > call with a.out (and later ELF) binaries, while iBCS2 mandated use of > "lcall 7,0" syscalls and COFF binaries. So iBCS2 support was an > optional thing that you had to explicitly configure the kernel to > support, and while it was quite complete, it was not Linux's native > userspace interface. > So I've written a libc-like library for Linux ABI for my kexec the FreeBSD kernel project which produces a Linux binary inside the FreeBSD build system. I target powerpc64, arm64 and aarch64 (with plans for armv7 maybe and riscv64 for sure). They all have different system call numbers, slightly different system call encodings and the ERRNOs are different > 34, with not all the errnos defined on all five of these architectures. There's also variation in how the different structures one passes to system calls are laid out such that I need to have different arch .h files to describe them (cf stat, dirent, termios). There are generic versions, but even this small selection of architectures has departures for some or all of them from the generics. All of that is from this year, using only ELF binaries and trying like heck to avoid the oldest, legacy system calls and using only the newer ones that aren't crazy to use. Of course, that's all "chump change" in this project since the evolved kexec interface on Linux is somewhat different between architectures, involves many special magic things you just have to know to use, and is rather Linux centric... And also the evolved FreeBSD per-arch boot interface, which has all those things, but with somewhat different details and somewhat FreeBSD centric... Warner > [1] https://www.linux.co.cr/free-unix-os/review/acrobat/940612.pdf > > Story time: at one point in the early 90's, MIT purchased a site > license for a proprietary spreadsheet product for ISC Unix, which we > planned to run on Linux systems at MIT using iBCS2. When I contacted > Michael Johnson[2], the engineer at that company to implement support > for the site license ---- which was going to rely on checking the IP > address on the system to see if it was 18.x.y.z --- I found out that > Michael built and tested the spreadsheet using Linux with iBCS2 > emulation, and only *later* made sure it would actually run on ISC > Unix, because Linux was a much more pleasant development environment > than the System V alternatives. :-) > > [2] Michael later was one of the founders of Red Hat. > > In any case, while in practice some platforms use a unique set of code > points for system calls and signal numbers (thos are mostly the older > architectures which exist mostly for historic interest), most > platforms which run Linux today actually use a consistent set of > system call and signal numbers. > > That being said, we did implement many of the System V extensions, > mostly because there was demand from the proprietary software vendors > who needed to be convinced to port their applications from Solars, > HPUX, AIX, etc., to Linux. > > Mercifully, Linux never implemented Streams (thank $DEITY Oracle > didn't make that a requirement :-) and we did have BSD job control > from the earliest days. That happened because in early 1992, I > considered Job Control to be a highly important feature that Linux > **had** to have, and so I sat down with the POSIX.1 specification, and > implemented job control from the spec. The reason why Linux's tty > layer has a bit of a System V "flavor" at least from a system call > perspective has nothing to do the system call ABI, and more to do with > the fact that apparently representatives from System V derivatives > seemed to have a dominant role on the POSIX committee. > > - Ted > [-- Attachment #2: Type: text/html, Size: 6043 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 20:38 ` Theodore Ts'o 2023-01-30 21:01 ` Warner Losh @ 2023-01-30 21:10 ` Clem Cole 1 sibling, 0 replies; 69+ messages in thread From: Clem Cole @ 2023-01-30 21:10 UTC (permalink / raw) To: Theodore Ts'o, The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1007 bytes --] On Mon, Jan 30, 2023 at 3:39 PM Theodore Ts'o <tytso@mit.edu> wrote: > apparently representatives from System V derivatives > seemed to have a dominant role on the POSIX committee. > I can personally attest (having been in the room during many of that those discussions) this is a true statement. The early versions (certainly thru .1 - the original system called Interface), AT&T team, and a number of vendors particularly the European ones - tried hard to push the SVID to be POSIX, although many of us had used a lot of BSD in our systems fought back. Can not say it was a fun time. The problem was everyone in the room wanted to be the big dog and to have all the food -- no one could really admit that we were all in it together and the real competition was elsewhere. FWIW: Keith Bostic occasionally came to some of those meetings from CSRG to some of those meetings and was amazingly gracious/patient. It's why 4.4 had a number of things in that made it closer to POSIX. ᐧ [-- Attachment #2: Type: text/html, Size: 2142 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 15:16 ` Dan Cross 2023-01-30 15:27 ` Larry McVoy @ 2023-01-30 16:03 ` Bakul Shah 2023-01-30 16:07 ` Larry McVoy 2023-01-30 16:18 ` Ralph Corderoy 1 sibling, 2 replies; 69+ messages in thread From: Bakul Shah @ 2023-01-30 16:03 UTC (permalink / raw) To: Dan Cross; +Cc: tuhs > On Jan 30, 2023, at 7:18 AM, Dan Cross <crossd@gmail.com> wrote: > > There was no job control on plan9 and I can't say I ever missed it. Just yesterday I realized running two “make -j 8” in parallel was making them both go real slow so I stopped one of them with ^Z and continued it once the other make finished. This use case can’t be handled with more windows. ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 16:03 ` Bakul Shah @ 2023-01-30 16:07 ` Larry McVoy 2023-01-30 16:13 ` Bakul Shah 2023-01-30 16:17 ` Dan Cross 2023-01-30 16:18 ` Ralph Corderoy 1 sibling, 2 replies; 69+ messages in thread From: Larry McVoy @ 2023-01-30 16:07 UTC (permalink / raw) To: Bakul Shah; +Cc: tuhs On Mon, Jan 30, 2023 at 08:03:42AM -0800, Bakul Shah wrote: > > > > On Jan 30, 2023, at 7:18 AM, Dan Cross <crossd@gmail.com> wrote: > > > > There was no job control on plan9 and I can't say I ever missed it. > > Just yesterday I realized running two ???make -j 8??? in parallel was making > them both go real slow so I stopped one of them with ^Z and continued > it once the other make finished. This use case can???t be handled with more > windows. If you don't have job control, do you not have ^C to kill one of the make jobs? I guess you open another window and ps and kill it but if the machine is already thrashing that is gonna be unpleasant. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 16:07 ` Larry McVoy @ 2023-01-30 16:13 ` Bakul Shah 2023-01-30 16:22 ` Steve Nickolas 2023-01-30 16:17 ` Dan Cross 1 sibling, 1 reply; 69+ messages in thread From: Bakul Shah @ 2023-01-30 16:13 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs On Jan 30, 2023, at 8:07 AM, Larry McVoy <lm@mcvoy.com> wrote: > > On Mon, Jan 30, 2023 at 08:03:42AM -0800, Bakul Shah wrote: >> >> >>>> On Jan 30, 2023, at 7:18 AM, Dan Cross <crossd@gmail.com> wrote: >>> >>> There was no job control on plan9 and I can't say I ever missed it. >> >> Just yesterday I realized running two ???make -j 8??? in parallel was making >> them both go real slow so I stopped one of them with ^Z and continued >> it once the other make finished. This use case can???t be handled with more >> windows. > > If you don't have job control, do you not have ^C to kill one of the > make jobs? I guess you open another window and ps and kill it but > if the machine is already thrashing that is gonna be unpleasant. Yes but then you lose a bunch of work. You don’t want to restart, you just want to delay. ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 16:13 ` Bakul Shah @ 2023-01-30 16:22 ` Steve Nickolas 0 siblings, 0 replies; 69+ messages in thread From: Steve Nickolas @ 2023-01-30 16:22 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 298 bytes --] On Mon, 30 Jan 2023, Bakul Shah wrote: > Yes but then you lose a bunch of work. You don’t want to restart, > you just want to delay. If it restarts, then there's something very wrong with your Makefile. make is designed to pick up where it left off if it dies before finishing. -uso. ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 16:07 ` Larry McVoy 2023-01-30 16:13 ` Bakul Shah @ 2023-01-30 16:17 ` Dan Cross 1 sibling, 0 replies; 69+ messages in thread From: Dan Cross @ 2023-01-30 16:17 UTC (permalink / raw) To: Larry McVoy; +Cc: Bakul Shah, tuhs On Mon, Jan 30, 2023 at 11:07 AM Larry McVoy <lm@mcvoy.com> wrote: > On Mon, Jan 30, 2023 at 08:03:42AM -0800, Bakul Shah wrote: > > > On Jan 30, 2023, at 7:18 AM, Dan Cross <crossd@gmail.com> wrote: > > > There was no job control on plan9 and I can't say I ever missed it. > > > > Just yesterday I realized running two ???make -j 8??? in parallel was making > > them both go real slow so I stopped one of them with ^Z and continued > > it once the other make finished. This use case can???t be handled with more > > windows. > > If you don't have job control, do you not have ^C to kill one of the > make jobs? I guess you open another window and ps and kill it but > if the machine is already thrashing that is gonna be unpleasant. You do, but it's not a kernel-level thing; there's no TTY abstraction with an attendant driver. Instead, the window system will interpret DEL as an interrupt request and send a note to the process group running in that window. Plan 9 didn't have signals; rather, there were "notes", that were little strings that could be sent between processes. It was the responsibility of the receiver to parse these and take appropriate action in a note handler; there was a "stop" note that could be used to pause a process. One could presumably use that to pause a process group that was using excessive CPU. - Dan C. ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 16:03 ` Bakul Shah 2023-01-30 16:07 ` Larry McVoy @ 2023-01-30 16:18 ` Ralph Corderoy 2023-01-30 16:41 ` [TUHS] job control (Re: " Bakul Shah 2023-01-30 19:07 ` [TUHS] " Dan Cross 1 sibling, 2 replies; 69+ messages in thread From: Ralph Corderoy @ 2023-01-30 16:18 UTC (permalink / raw) To: tuhs Hi Bakul, > > There was no job control on plan9 and I can't say I ever missed it. > > Just yesterday I realized running two “make -j 8” in parallel was > making them both go real slow so I stopped one of them with ^Z and > continued it once the other make finished. This use case can’t be > handled with more windows. If I lacked job control in that situation, I'd either SIGSTOP one of the two with kill(1) for a later SIGCONT or renice it to hardly get a look in until its peer had finished. (The TTY's susp character for job control is SIGTSTP.) -- Cheers, Ralph. ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] job control (Re: Re: FD 2 2023-01-30 16:18 ` Ralph Corderoy @ 2023-01-30 16:41 ` Bakul Shah 2023-01-30 19:07 ` [TUHS] " Dan Cross 1 sibling, 0 replies; 69+ messages in thread From: Bakul Shah @ 2023-01-30 16:41 UTC (permalink / raw) To: Ralph Corderoy; +Cc: tuhs On Jan 30, 2023, at 8:19 AM, Ralph Corderoy <ralph@inputplus.co.uk> wrote: > > Hi Bakul, > >>> There was no job control on plan9 and I can't say I ever missed it. >> >> Just yesterday I realized running two “make -j 8” in parallel was >> making them both go real slow so I stopped one of them with ^Z and >> continued it once the other make finished. This use case can’t be >> handled with more windows. > > If I lacked job control in that situation, I'd either SIGSTOP one of the > two with kill(1) for a later SIGCONT or renice it to hardly get a look > in until its peer had finished. (The TTY's susp character for job > control is SIGTSTP.) Unfortunately renice command can only be used by mere users to *increase* niceness, not decrease. Agreed that you don’t need a tty discipline for SIGSTOP but it is quite convenient! Note that even plan9 allows killing a process by hitting a single key but I suppose that is done in a different way. Steve Nickolas made a comment about how rerunning make should simply continue from where it left off. Unfortunately many do not. A typical silent error is an output file is created but the program is killed before it can finish the job. The next time around this program won’t run since the output already exists! Or you have a “make world” situation where everything is removed before building anything! ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 16:18 ` Ralph Corderoy 2023-01-30 16:41 ` [TUHS] job control (Re: " Bakul Shah @ 2023-01-30 19:07 ` Dan Cross 1 sibling, 0 replies; 69+ messages in thread From: Dan Cross @ 2023-01-30 19:07 UTC (permalink / raw) To: Ralph Corderoy; +Cc: tuhs On Mon, Jan 30, 2023 at 11:19 AM Ralph Corderoy <ralph@inputplus.co.uk> wrote: > > > There was no job control on plan9 and I can't say I ever missed it. > > > > Just yesterday I realized running two “make -j 8” in parallel was > > making them both go real slow so I stopped one of them with ^Z and > > continued it once the other make finished. This use case can’t be > > handled with more windows. > > If I lacked job control in that situation, I'd either SIGSTOP one of the > two with kill(1) for a later SIGCONT or renice it to hardly get a look > in until its peer had finished. (The TTY's susp character for job > control is SIGTSTP.) I think that Bakul's point was that there wasn't an analogue for SIGTSTP in plan 9. You _could_ drop a `stop` into a process's /proc/$pid/note, which was the Unix equivalent of sending `SIGSTOP` (and I was a bit wrong earlier; that was handled by the proc driver, not the process). I don't believe there was a binding for that in the window system, though. It's funny, as I thought about it a bit more, the existence of the window system model sort of proves that there's nothing intrinsic about how it worked that would preclude one writing, basically, a terminal-driver in user space. No one was ever motivated to do so, but I don't see why one couldn't have implemented job control as a userspace primitive building on top of the existing proc/note machinery. - Dan C. ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 7:50 ` arnold 2023-01-30 8:09 ` Rob Pike @ 2023-01-30 13:26 ` John Cowan 2023-01-30 14:30 ` arnold 1 sibling, 1 reply; 69+ messages in thread From: John Cowan @ 2023-01-30 13:26 UTC (permalink / raw) To: arnold; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 556 bytes --] On Mon, Jan 30, 2023 at 2:50 AM <arnold@skeeve.com> wrote: What I really like is how in V8 - V10 /dev/tty was a (sym)link to /dev/fd/3, and init simply did one more dup call. That eliminated the special tty device driver and was a lovely generalization / simplification. It's too bad this was never picked in the commercial Unixes or in Linux. That's problematic. I often need to redirect 2>&1 in order to get a stream of both output and error into a file or into less(1), without interfering with *input* from the terminal, as for example a password. [-- Attachment #2: Type: text/html, Size: 1061 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 13:26 ` John Cowan @ 2023-01-30 14:30 ` arnold 0 siblings, 0 replies; 69+ messages in thread From: arnold @ 2023-01-30 14:30 UTC (permalink / raw) To: cowan, arnold; +Cc: tuhs John Cowan <cowan@ccil.org> wrote: > On Mon, Jan 30, 2023 at 2:50 AM <arnold@skeeve.com> wrote: > > > What I really like is how in V8 - V10 /dev/tty was a (sym)link to /dev/fd/3, > > and init simply did one more dup call. That eliminated the special tty > > device > > driver and was a lovely generalization / simplification. It's too bad this > > was never picked in the commercial Unixes or in Linux. > > That's problematic. I often need to redirect 2>&1 in order to get a stream > of both output and error into a file or into less(1), without interfering > with *input* from the terminal, as for example a password. I don't see how. Input is from fd 0. fd 3 is open on the original terminal device by init, so even if you closed fd 0, opening /dev/tty gets you fd 3 gets you the original tty. Granted, someone could also redirect fd 3, but that's unlikely in most cases. Arnold ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-29 19:20 ` Ron Natalie 2023-01-29 20:25 ` Warner Losh @ 2023-01-30 0:25 ` Phil Budne 2023-01-30 2:08 ` Warner Losh 1 sibling, 1 reply; 69+ messages in thread From: Phil Budne @ 2023-01-30 0:25 UTC (permalink / raw) To: tuhs Ron Natalie wrote: > Warner Losh wrote: > >"The main loop of the shell went as follows: > >1) The shell closed all its open files, then opened the terminal > >special file for standard input and output (file descriptors 0 and 1). > > > Unfortunately, the source code says otherwise. None of shells V6, PWB, > V7 do anything like is mentioned above. They assume 0 and 1 (and 2) > are already open. > The only fd redirection they do is when you do pipes or redirection on > the command line. > > Where this is done is, as I posted earlier, in /etc/init. Init opens > the tty device and dups it to 1 and then invokes either the shell (if > we're in single user mode) or getty for interactive mode. > This was done in V6 and PWB (1). In V7, init added a second dup for > file descriptor 2. I think the text Warner quoted applied to only the pre-fork version of the system, since it's preceeded by: "Processes (independently executing entities) existed very early in PDP-7 Unix. There were in fact precisely two of them, one for each of the two terminals attached to the machine. There was no fork, wait, or exec. There was an exit, but its meaning was rather different, as will be seen. and ends with: "4) The command did its work, then terminated by calling exit. The exit call caused the system to read in a fresh copy of the shell over the terminated command, then to jump to its start (and thus in effect to go to step 1)." In the (late) PDP-7 Unix we have sources for, FDs 1 & 2 are established in init at labels init1 (for the user on the console tty) and init2 (for the user on the display & display keyboard) after forking and doing the job of the login executable: https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/init.s A remaining mystery about the set of PDP-7 Unix sources we have is that cat.s (and only cat.s?) writes error messages to FD 8, but I haven't seen any place that sets FD 8: https://github.com/DoctorWkt/pdp7-unix/blob/master/scans/cat.s#L43 https://github.com/DoctorWkt/pdp7-unix/blob/master/scans/cat.s#L45 https://github.com/DoctorWkt/pdp7-unix/blob/master/scans/cat.s#L51 Listing scan at: https://www.tuhs.org/Archive/Distributions/Research/McIlroy_v0/06-5-12.pdf#page=21 ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-30 0:25 ` Phil Budne @ 2023-01-30 2:08 ` Warner Losh 0 siblings, 0 replies; 69+ messages in thread From: Warner Losh @ 2023-01-30 2:08 UTC (permalink / raw) To: Phil Budne; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 2476 bytes --] On Sun, Jan 29, 2023, 5:25 PM Phil Budne <phil@ultimate.com> wrote: > Ron Natalie wrote: > > Warner Losh wrote: > > >"The main loop of the shell went as follows: > > >1) The shell closed all its open files, then opened the terminal > > >special file for standard input and output (file descriptors 0 and 1). > > > > > Unfortunately, the source code says otherwise. None of shells V6, PWB, > > V7 do anything like is mentioned above. They assume 0 and 1 (and 2) > > are already open. > > The only fd redirection they do is when you do pipes or redirection on > > the command line. > > > > Where this is done is, as I posted earlier, in /etc/init. Init opens > > the tty device and dups it to 1 and then invokes either the shell (if > > we're in single user mode) or getty for interactive mode. > > This was done in V6 and PWB (1). In V7, init added a second dup for > > file descriptor 2. > > I think the text Warner quoted applied to only the pre-fork version of > the system, since it's preceeded by: > > "Processes (independently executing entities) existed very early in > PDP-7 Unix. There were in fact precisely two of them, one for each > of the two terminals attached to the machine. There was no fork, > wait, or exec. There was an exit, but its meaning was rather > different, as will be seen. > > and ends with: > > "4) The command did its work, then terminated by calling exit. The > exit call caused the system to read in a fresh copy of the shell > over the terminated command, then to jump to its start (and thus in > effect to go to step 1)." > > In the (late) PDP-7 Unix we have sources for, FDs 1 & 2 are > established in init at labels init1 (for the user on the console tty) > and init2 (for the user on the display & display keyboard) after forking > and doing the job of the login executable: > > https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/init.s It looks like 0 & 1 to me. Am I missing something? Warner > > A remaining mystery about the set of PDP-7 Unix sources we have is > that cat.s (and only cat.s?) writes error messages to FD 8, but I > haven't seen any place that sets FD 8: > > https://github.com/DoctorWkt/pdp7-unix/blob/master/scans/cat.s#L43 > https://github.com/DoctorWkt/pdp7-unix/blob/master/scans/cat.s#L45 > https://github.com/DoctorWkt/pdp7-unix/blob/master/scans/cat.s#L51 > > Listing scan at: > > https://www.tuhs.org/Archive/Distributions/Research/McIlroy_v0/06-5-12.pdf#page=21 > > [-- Attachment #2: Type: text/html, Size: 3959 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-21 17:34 ` Warner Losh 2023-01-21 17:50 ` Warner Losh @ 2023-01-21 18:27 ` Clem Cole 2023-01-22 10:56 ` Jaap Akkerhuis via TUHS 1 sibling, 1 reply; 69+ messages in thread From: Clem Cole @ 2023-01-21 18:27 UTC (permalink / raw) To: Warner Losh; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 343 bytes --] On Sat, Jan 21, 2023 at 12:34 PM Warner Losh <imp@bsdimp.com> wrote: > It looks to be a mixed bag in 5th edition. Cc, ac, comm and find all > printf the errors. Diff uses writes to fd 2. I didn't catalog further, but > this kinda looks like a developing convention, not yet fully realized. . > Fair enough and that makes sense... ᐧ [-- Attachment #2: Type: text/html, Size: 1140 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [TUHS] Re: FD 2 2023-01-21 18:27 ` Clem Cole @ 2023-01-22 10:56 ` Jaap Akkerhuis via TUHS 0 siblings, 0 replies; 69+ messages in thread From: Jaap Akkerhuis via TUHS @ 2023-01-22 10:56 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1.1: Type: text/plain, Size: 573 bytes --] > On 21 Jan 2023, at 19:27, Clem Cole <clemc@ccc.com> wrote: > > > > On Sat, Jan 21, 2023 at 12:34 PM Warner Losh <imp@bsdimp.com <mailto:imp@bsdimp.com>> wrote: >> It looks to be a mixed bag in 5th edition. Cc, ac, comm and find all printf the errors. Diff uses writes to fd 2. I didn't catalog further, but this kinda looks like a developing convention, not yet fully realized. . > Fair enough and that makes sense... > ᐧ I do remember that pr -p actually read from FD 2. It probably still does. Very useful to align paper in the printer. jaap [-- Attachment #1.2: Type: text/html, Size: 1765 bytes --] [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 267 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
end of thread, other threads:[~2023-01-31 21:40 UTC | newest] Thread overview: 69+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-01-20 22:44 [TUHS] FD 2 ron minnich 2023-01-20 22:54 ` [TUHS] " G. Branden Robinson 2023-01-20 22:56 ` Rob Pike 2023-01-20 23:11 ` Larry McVoy 2023-01-20 23:14 ` Rob Pike 2023-01-20 23:22 ` Larry McVoy 2023-01-20 23:13 ` Douglas McIlroy 2023-01-21 3:37 ` Jon Steinhart 2023-01-21 15:42 ` Clem Cole 2023-01-21 17:34 ` Warner Losh 2023-01-21 17:50 ` Warner Losh 2023-01-21 18:26 ` Clem Cole 2023-01-21 18:37 ` Warner Losh 2023-01-22 11:05 ` Jonathan Gray 2023-01-22 21:23 ` Warner Losh 2023-01-22 22:10 ` ron minnich 2023-01-23 7:30 ` arnold 2023-01-23 8:32 ` James Johnston 2023-01-23 8:58 ` G. Branden Robinson 2023-01-23 11:49 ` Brantley Coile 2023-01-23 14:25 ` Ronald Natalie 2023-01-23 17:43 ` Brantley Coile 2023-01-23 16:59 ` Douglas McIlroy 2023-01-24 7:21 ` arnold 2023-01-29 18:51 ` Warner Losh 2023-01-29 19:20 ` Ron Natalie 2023-01-29 20:25 ` Warner Losh 2023-01-30 7:50 ` arnold 2023-01-30 8:09 ` Rob Pike 2023-01-30 15:02 ` Larry McVoy 2023-01-30 15:16 ` Dan Cross 2023-01-30 15:27 ` Larry McVoy 2023-01-30 15:35 ` Dan Cross 2023-01-30 15:45 ` Larry McVoy 2023-01-30 16:09 ` Dan Cross 2023-01-30 16:18 ` Larry McVoy 2023-01-30 19:03 ` Dan Cross 2023-01-30 19:12 ` Brantley Coile 2023-01-30 21:24 ` Larry McVoy 2023-01-30 22:15 ` Rob Pike 2023-01-30 22:50 ` ron minnich 2023-01-30 23:05 ` [TUHS] Child of plan9? (Re: " Bakul Shah 2023-01-31 3:19 ` [TUHS] " Andrew Warkentin 2023-01-30 16:21 ` [TUHS] " Steve Nickolas 2023-01-30 16:27 ` Larry McVoy 2023-01-30 16:32 ` ron minnich 2023-01-30 16:40 ` Clem Cole 2023-01-30 19:55 ` Lawrence Stewart 2023-01-31 21:27 ` Dave Horsfall 2023-01-30 16:48 ` Theodore Ts'o 2023-01-30 16:57 ` Andy Kosela 2023-01-30 17:04 ` Warner Losh 2023-01-30 20:38 ` Theodore Ts'o 2023-01-30 21:01 ` Warner Losh 2023-01-30 21:10 ` Clem Cole 2023-01-30 16:03 ` Bakul Shah 2023-01-30 16:07 ` Larry McVoy 2023-01-30 16:13 ` Bakul Shah 2023-01-30 16:22 ` Steve Nickolas 2023-01-30 16:17 ` Dan Cross 2023-01-30 16:18 ` Ralph Corderoy 2023-01-30 16:41 ` [TUHS] job control (Re: " Bakul Shah 2023-01-30 19:07 ` [TUHS] " Dan Cross 2023-01-30 13:26 ` John Cowan 2023-01-30 14:30 ` arnold 2023-01-30 0:25 ` Phil Budne 2023-01-30 2:08 ` Warner Losh 2023-01-21 18:27 ` Clem Cole 2023-01-22 10:56 ` Jaap Akkerhuis via TUHS
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).