* [TUHS] Happy birthday, Dennis Ritchie! @ 2017-09-08 20:54 Dave Horsfall 2017-09-08 21:04 ` Noel Chiappa ` (3 more replies) 0 siblings, 4 replies; 204+ messages in thread From: Dave Horsfall @ 2017-09-08 20:54 UTC (permalink / raw) Sadly no longer with us (he exited in 2011), he was forked in 1941. Just think, if it wasn't for him and Ken, we'd all be running Windoze, and thinking it's wonderful. A Unix bigot through and through, I remain, -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! @ 2017-09-08 21:04 ` Noel Chiappa 2017-09-08 21:09 ` Michael Kjörling 2017-09-08 22:28 ` Steve Nickolas 0 siblings, 2 replies; 204+ messages in thread From: Noel Chiappa @ 2017-09-08 21:04 UTC (permalink / raw) > From: Dave Horsfall <dave at horsfall.org> > Just think, if it wasn't for him and Ken, we'd all be running Windoze, > and thinking it's wonderful. It's actually worse than that. We'd be running a Windows even worse than current Windows (which has managed to pick up a few decent ideas from places like Unix). Noel ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-08 21:04 ` Noel Chiappa @ 2017-09-08 21:09 ` Michael Kjörling 2017-09-09 1:16 ` Wesley Parish 2017-09-08 22:28 ` Steve Nickolas 1 sibling, 1 reply; 204+ messages in thread From: Michael Kjörling @ 2017-09-08 21:09 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 537 bytes --] On 8 Sep 2017 17:04 -0400, from jnc at mercury.lcs.mit.edu (Noel Chiappa): > We'd be running a Windows even worse than current Windows (which has managed > to pick up a few decent ideas from places like Unix). Like directories, and free-form files (collections of bytes as opposed to collections of records)? -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-08 21:09 ` Michael Kjörling @ 2017-09-09 1:16 ` Wesley Parish 2017-09-09 1:30 ` [TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!) Greg 'groggy' Lehey 2017-09-09 4:34 ` [TUHS] Happy birthday, Dennis Ritchie! Steve Johnson 0 siblings, 2 replies; 204+ messages in thread From: Wesley Parish @ 2017-09-09 1:16 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1444 bytes --] 'fraid so. The Unix directory structure and the correlating free-form file competed with the file-as- record-structure and directory-as-record-structure in the seventies and eighties. The competition had finished by the nineties, and hardly anybody remembers it now. Seriously, how many grandmothers can you think of who would know how to allocate disk space for a photo of their grandkids? Who would be able to guess how many bytes a letter might take up? Free-form files and directory nodes (with the corresponding requirement that the OS know how to allocate and reallocate disk space) helped democratize computing. Just my 0.02c :) Wesley Parish Quoting Michael Kjörling <michael at kjorling.se>: > On 8 Sep 2017 17:04 -0400, from jnc at mercury.lcs.mit.edu (Noel Chiappa): > > We'd be running a Windows even worse than current Windows (which has > managed > > to pick up a few decent ideas from places like Unix). > > Like directories, and free-form files (collections of bytes as opposed > to collections of records)? > > -- > Michael Kjörling ⢠https://michael.kjorling.se ⢠> michael at kjorling.se > âPeople who think they know everything really annoy > those of us who know we donât.â (Bjarne Stroustrup) > "I have supposed that he who buys a Method means to learn it." - Ferdinand Sor, Method for Guitar "A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!) 2017-09-09 1:16 ` Wesley Parish @ 2017-09-09 1:30 ` Greg 'groggy' Lehey 2017-09-09 1:43 ` Warner Losh ` (2 more replies) 2017-09-09 4:34 ` [TUHS] Happy birthday, Dennis Ritchie! Steve Johnson 1 sibling, 3 replies; 204+ messages in thread From: Greg 'groggy' Lehey @ 2017-09-09 1:30 UTC (permalink / raw) On Saturday, 9 September 2017 at 13:16:30 +1200, Wesley Parish wrote: > 'fraid so. The Unix directory structure and the correlating > free-form file competed with the file-as- record-structure and > directory-as-record-structure in the seventies and eighties. The > competition had finished by the nineties, and hardly anybody > remembers it now. Sorry, I don't understand this. Can you give an example of file-as-record and directory-as-record? Some of it suggests MVS, but not quite. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170909/b9b9966f/attachment.sig> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!) 2017-09-09 1:30 ` [TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!) Greg 'groggy' Lehey @ 2017-09-09 1:43 ` Warner Losh 2017-09-09 1:50 ` Wesley Parish 2017-09-11 17:26 ` [TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!) Paul Winalski 2 siblings, 0 replies; 204+ messages in thread From: Warner Losh @ 2017-09-09 1:43 UTC (permalink / raw) On Fri, Sep 8, 2017 at 7:30 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote: > On Saturday, 9 September 2017 at 13:16:30 +1200, Wesley Parish wrote: > > 'fraid so. The Unix directory structure and the correlating > > free-form file competed with the file-as- record-structure and > > directory-as-record-structure in the seventies and eighties. The > > competition had finished by the nineties, and hardly anybody > > remembers it now. > > Sorry, I don't understand this. Can you give an example of > file-as-record and directory-as-record? Some of it suggests MVS, but > not quite. > See VMS's RMS: https://en.wikipedia.org/wiki/Record_Management_Services for a representative competitor. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170908/c6b85a0a/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!) 2017-09-09 1:30 ` [TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!) Greg 'groggy' Lehey 2017-09-09 1:43 ` Warner Losh @ 2017-09-09 1:50 ` Wesley Parish 2017-09-09 13:59 ` [TUHS] File-as-record Arthur Krewat 2017-09-11 17:26 ` [TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!) Paul Winalski 2 siblings, 1 reply; 204+ messages in thread From: Wesley Parish @ 2017-09-09 1:50 UTC (permalink / raw) I picked up a book in the early nineties called File Structures or File Systems: I've forgotten which, because I didn't read it as much as I had intended. It covered the IBM MVS mainframe dataset file and directory structure and the Unix file and directory structure. And yes, I was referring to the MVS dataset, as much of it as I can remember from that book. (I sorry I can't recall the exact title: the book is somewhere at the bottom of a pile of other books from my last move several years ago.) Wesley Parish Quoting Greg 'groggy' Lehey <grog at lemis.com>: > On Saturday, 9 September 2017 at 13:16:30 +1200, Wesley Parish wrote: > > 'fraid so. The Unix directory structure and the correlating > > free-form file competed with the file-as- record-structure and > > directory-as-record-structure in the seventies and eighties. The > > competition had finished by the nineties, and hardly anybody > > remembers it now. > > Sorry, I don't understand this. Can you give an example of > file-as-record and directory-as-record? Some of it suggests MVS, but > not quite. > > Greg > -- > Sent from my desktop computer. > Finger grog at lemis.com for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA > "I have supposed that he who buys a Method means to learn it." - Ferdinand Sor, Method for Guitar "A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] File-as-record 2017-09-09 1:50 ` Wesley Parish @ 2017-09-09 13:59 ` Arthur Krewat 0 siblings, 0 replies; 204+ messages in thread From: Arthur Krewat @ 2017-09-09 13:59 UTC (permalink / raw) Not sure I quite get this "file as record" thing. On TOPS-10, you create a file, edit a file, you don't have to allocate space for it before you use it. Sure, it's made up of "blocks" - and writing to the file requires you to do it in blocks. But allocating those blocks was done on as the fly as you wrote to it. Also, the first thing I did was to make my own routines that would allow the program to read/write in random-size chunks, blocking as it needs to. Is the distrinction that the operating system (libraries) allowed you to read/write random size chunks? If so, the underlying structure of a UNIX filesystem still required block I/O. It was just hidden from the programmer. But for peak performance, you still needed to do things in big enough chunks (blocks). If I had known that random-size chunk read/writes were a "thing" I would have added it to the TOPS-10 monitor sources and submitted it back to DEC :) AAK PS: First TOPS-10 monitor was 1964 ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!) 2017-09-09 1:30 ` [TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!) Greg 'groggy' Lehey 2017-09-09 1:43 ` Warner Losh 2017-09-09 1:50 ` Wesley Parish @ 2017-09-11 17:26 ` Paul Winalski 2 siblings, 0 replies; 204+ messages in thread From: Paul Winalski @ 2017-09-11 17:26 UTC (permalink / raw) On 9/8/17, Greg 'groggy' Lehey <grog at lemis.com> wrote: > On Saturday, 9 September 2017 at 13:16:30 +1200, Wesley Parish wrote: >> 'fraid so. The Unix directory structure and the correlating >> free-form file competed with the file-as- record-structure and >> directory-as-record-structure in the seventies and eighties. The >> competition had finished by the nineties, and hardly anybody >> remembers it now. > > Sorry, I don't understand this. Can you give an example of > file-as-record and directory-as-record? Some of it suggests MVS, but > not quite. At least in the IBM world, disk drives originally didn't have their tracks formatted into fixed-length sectors as they are today. Early on in the business world, everything was record-oriented. Except for the very largest ones, computers didn't have the either the speed or the memory to do database processing as we now know it. For most business shops, there was sequential file processing, random access (where you had to know the cylinder and head position of the record you wanted), and indexed sequential access (by the value of a key field in the record). Disks in those days (pre-mid 70s) were not formatted in fixed-length sectors as they are today. Instead, records could be arbitrary length (limited by the capacity of a single disk track, of course) and had three fields: a count field containing the number of bytes in the record, a key field for indexed access, and a data field. This format was called CKD (count/key/data). On IBM disks, records were addressed by a number of the form CCCHHRR, where CCC is the cylinder, HH the head, and RR the record on the track (for the data cell drive, there was also a two digit bin number). The disk controller could also do a "seek by key" operation. This would scan the track for a record whose key field matched the given key. It was used to implement indexed sequential access. For System/360/370, the OSes for the smaller, slower systems, such as Basic Operating System (BOS) and Disk Operating System (DOS and DOS/VS) did not have an on-disk file system at all. You had to manually allocate the files on the disk and you used directives in job control language (JCL) to tell the OS where your file was and to assign it a logical unit number for the program to use (FORTRAN's I/O reflects this). The OSes for larger systems such as OS/MVS (and perhaps its predecessor, OS/MVT?) had a catalog file that could automate the process of assigning files to locations on disk. This was the closest these OSes came to a modern directory-oriented file system. In the business world this is not as grim as it might seem. Most businesses had a small number of files that didn't change very often. For example, a college has accounts payable/receivable, student academic records, alumni/charitable giving, and payroll and personnel. These get allocated once and, provided the initial disk allocation is sufficient, don't have to move. On the programming side, there wasn't either the memory capacity or processing power to implement a modern disk file system. One of the first computers I worked with was a System/360 model 25 running DOS/360. The machine had 48K of core memory, 12K of which was for the OS, leaving 36K for programs. No virtual memory. The OS had an 8K resident kernel and two 2K overlay areas: the physical transient area (for controlling hardware; the forerunners of what we now call device drivers) and the logical transient area (for the parts of program I/O that had to operate in privileged mode, and for most OS system service functions). For I/O, each program contained library routines called "access methods", which took logical file I/O operations (open, close, read, write, seek, etc.), built the appropriate I/O channel programs, and executed the EXCP (execute channel program) OS primitive. The access methods operated on logical I/O unit numbers, which as previously noted were associated with places on-disk via JCL statements before the program started execution. The access methods were SAM (Sequential Access Method; records read/written in on-disk order), DAM (Direct Access Method; allowed seeking to an arbitrary record using CCCHHRR address), and ISAM (Indexed Sequential Access Method; allowed seeking to a record by key, and then reading/writing sequentially from there). The access methods and their capabilities mirrored the CKD disk format of the time. As disk hardware became denser and faster, and computers got more memory, it became more efficient to format the disk as a set of fixed-length sectors, which could be packed more densely and accessed faster than CKD records. Record blocking and unblocking was moved to the OS or application. Indexed access could be accomplished a lot faster using B-trees in the file. UNIX took the final step in this evolution by providing exclusively byte-stream I/O in the OS, and leaving record processing up to the application. Those of us from the record-oriented world found this a pain in the butt at first (application programmers were forced to roll their own record processing, something that the access methods did for you in the OS/360 world). But by 1990 it was generally recognized that stream I/O is the more appropriate OS primitive. -Paul W. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-09 1:16 ` Wesley Parish 2017-09-09 1:30 ` [TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!) Greg 'groggy' Lehey @ 2017-09-09 4:34 ` Steve Johnson 2017-09-09 13:04 ` William Cheswick 2017-09-09 15:55 ` Clem Cole 1 sibling, 2 replies; 204+ messages in thread From: Steve Johnson @ 2017-09-09 4:34 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 3354 bytes --] I'm not sure that the file and directory structure was all that innovative (after all, the biologists had been doing that kind of thing forever...). But the file as a lightweight flick-of-the-wrist-create-able entity was mind blowing. At the time, the IBM 360 required that you run a special job step to create a file (we're talking punched cards here). And then you had to pull that job step out of the deck because trying to create a file that already existed was an error. In the GE/Honeywell time sharing system, you had to invoke a subsystem that asked you 8 or 10 questions (name, what device was it on, how big is upon creation, how big could it grow to, what was its record size, etc.). It stored up your answers and then handed them to the OS. It was easy to get a question wrong, in which case it sent you back to the beginning to do the dance again. Most telling, when the file was finally created the subsystem exited with the happy message "Successful!" For people used to that world, "echo hello >hi" was literally jaw dropping. Many people had to have it explained twice, because they literally could not conceive of a file being created so easily. I had worked in the computing center for a couple of years, and probably gave more than my share of demos to mainframe users... Steve PS: It was about this time that a survey of the mainframe computer centers found that over 50% of the (costly, limited) disc space consisted of trailing blanks of 80-column card images stored on disc. ----- Original Message ----- From: "Wesley Parish" <wes.parish@paradise.net.nz> To:<tuhs at minnie.tuhs.org> Cc: Sent:Sat, 09 Sep 2017 13:16:30 +1200 (NZST) Subject:Re: [TUHS] Happy birthday, Dennis Ritchie! 'fraid so. The Unix directory structure and the correlating free-form file competed with the file-as- record-structure and directory-as-record-structure in the seventies and eighties. The competition had finished by the nineties, and hardly anybody remembers it now. Seriously, how many grandmothers can you think of who would know how to allocate disk space for a photo of their grandkids? Who would be able to guess how many bytes a letter might take up? Free-form files and directory nodes (with the corresponding requirement that the OS know how to allocate and reallocate disk space) helped democratize computing. Just my 0.02c :) Wesley Parish Quoting Michael Kjörling <michael at kjorling.se>: > On 8 Sep 2017 17:04 -0400, from jnc at mercury.lcs.mit.edu (Noel Chiappa): > > We'd be running a Windows even worse than current Windows (which has > managed > > to pick up a few decent ideas from places like Unix). > > Like directories, and free-form files (collections of bytes as opposed > to collections of records)? > > -- > Michael Kjörling ⢠https://michael.kjorling.se ⢠> michael at kjorling.se > âPeople who think they know everything really annoy > those of us who know we donât.â (Bjarne Stroustrup) > "I have supposed that he who buys a Method means to learn it." - Ferdinand Sor, Method for Guitar "A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170908/740587fc/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-09 4:34 ` [TUHS] Happy birthday, Dennis Ritchie! Steve Johnson @ 2017-09-09 13:04 ` William Cheswick 2017-09-09 17:26 ` Steve Nickolas ` (2 more replies) 2017-09-09 15:55 ` Clem Cole 1 sibling, 3 replies; 204+ messages in thread From: William Cheswick @ 2017-09-09 13:04 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 751 bytes --] Amen. There were a number of things that really sucked at the time. My least favorite: time sharing systems that didn’t allow type-ahead. Kids these days... > On 9Sep 2017, at 12:34 AM, Steve Johnson <scj at yaccman.com> wrote: > > For people used to that world, "echo hello >hi" was literally jaw dropping. Many people had to have it explained twice, because they literally could not conceive of a file being created so easily. I had worked in the computing center for a couple of years, and probably gave more than my share of demos to mainframe users... > > Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170909/ea7e6843/attachment-0001.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-09 13:04 ` William Cheswick @ 2017-09-09 17:26 ` Steve Nickolas 2017-09-09 17:49 ` Arthur Krewat 2017-09-09 20:33 ` Lawrence Stewart 2 siblings, 0 replies; 204+ messages in thread From: Steve Nickolas @ 2017-09-09 17:26 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 266 bytes --] On Sat, 9 Sep 2017, William Cheswick wrote: > Amen. There were a number of things that really sucked at the time. > My least favorite: time sharing systems that didn’t allow type-ahead. > > Kids these days... Oh geez. That sounds pants-on-head special. -uso. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-09 13:04 ` William Cheswick 2017-09-09 17:26 ` Steve Nickolas @ 2017-09-09 17:49 ` Arthur Krewat 2017-09-09 19:40 ` Steve Nickolas 2017-09-09 20:33 ` Lawrence Stewart 2 siblings, 1 reply; 204+ messages in thread From: Arthur Krewat @ 2017-09-09 17:49 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1127 bytes --] TOPS-10 allowed type-ahead, with the caveat that if a program exited with an error, it would intentionally clear the TTY buffer. Something I actually sorely miss. IIRC, the type-ahead buffer was only around 80 characters. If you exceeded it, it beeped at you ;) On 9/9/2017 9:04 AM, William Cheswick wrote: > Amen. There were a number of things that really sucked at the time. > My least favorite: time sharing systems that didn’t allow type-ahead. > > Kids these days... > >> On 9Sep 2017, at 12:34 AM, Steve Johnson <scj at yaccman.com >> <mailto:scj at yaccman.com>> wrote: >> >> For people used to that world, "echo hello >hi" was literally jaw >> dropping. Many people had to have it explained twice, because they >> literally could not conceive of a file being created so easily. I >> had worked in the computing center for a couple of years, and >> probably gave more than my share of demos to mainframe users... >> >> Steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170909/a4869f25/attachment-0001.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-09 17:49 ` Arthur Krewat @ 2017-09-09 19:40 ` Steve Nickolas 0 siblings, 0 replies; 204+ messages in thread From: Steve Nickolas @ 2017-09-09 19:40 UTC (permalink / raw) On Sat, 9 Sep 2017, Arthur Krewat wrote: > TOPS-10 allowed type-ahead, with the caveat that if a program exited with an > error, it would intentionally clear the TTY buffer. Something I actually > sorely miss. That's actually a nice-ish feature. > IIRC, the type-ahead buffer was only around 80 characters. If you exceeded > it, it beeped at you ;) Reminds me of the 15-key buffer in the PC BIOS, which also beeps if you run out. -uso. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-09 13:04 ` William Cheswick 2017-09-09 17:26 ` Steve Nickolas 2017-09-09 17:49 ` Arthur Krewat @ 2017-09-09 20:33 ` Lawrence Stewart 2017-09-09 21:56 ` Steve Johnson 2017-09-11 16:20 ` Paul Winalski 2 siblings, 2 replies; 204+ messages in thread From: Lawrence Stewart @ 2017-09-09 20:33 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 955 bytes --] What, you didn’t like IBM 2741 terminals that mechanically locked the keyboard? > On 2017, Sep 9, at 9:04 AM, William Cheswick <ches at cheswick.com> wrote: > > Amen. There were a number of things that really sucked at the time. > My least favorite: time sharing systems that didn’t allow type-ahead. > > Kids these days... > >> On 9Sep 2017, at 12:34 AM, Steve Johnson <scj at yaccman.com <mailto:scj at yaccman.com>> wrote: >> >> For people used to that world, "echo hello >hi" was literally jaw dropping. Many people had to have it explained twice, because they literally could not conceive of a file being created so easily. I had worked in the computing center for a couple of years, and probably gave more than my share of demos to mainframe users... >> >> Steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170909/3f96ceb6/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-09 20:33 ` Lawrence Stewart @ 2017-09-09 21:56 ` Steve Johnson 2017-09-10 1:27 ` Dave Horsfall 2017-09-11 16:20 ` Paul Winalski 1 sibling, 1 reply; 204+ messages in thread From: Steve Johnson @ 2017-09-09 21:56 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2793 bytes --] Part of that problem was probably electronic, not software. Many of the early terminals were half-duplex. The normal mode was that the terminal typed what came over the line, and the keyboard was locked. If you wanted to let the terminal send data, you needed to send a control character to unlock the keyboard, and then another one to lock it when you wanted to send data again. As you may know, the first PDP-11 at Bell Labs was financed by the patent department because there were very draconian rules about submitting patents (every page had to have exactly 50 numbered lines, lines could not be blank, numbers must be in order, etc.) A change on page 3 of a 25-page patent application could mean that the whole thing had to be retyped (yes, manually...). That need drove a lot of the early nroff work. And, when upper/lower case terminals became common, many still had half duplex interfaces. When the Unix software got good enough, it started to get used by real typists, who were used to electric typewriters. There was bitter complaint about the half duplex (keyboard lock) mode -- the typists were so fast that when the keyboard locked they could break their fingernails! Full duplex pretty much solved that problem, and Unix, as far as I remember, embraced it earlier than most other systems. Steve PS: The Usenix publication ";login:" got its name because that's what a half-duplex system wrote for the login message when viewed on a full duplex terminal. The ; and : were actually control characters... ----- Original Message ----- From: "Lawrence Stewart" <stewart@serissa.com> To:"William Cheswick" <ches at cheswick.com> Cc:"TUHS main list" <tuhs at minnie.tuhs.org> Sent:Sat, 9 Sep 2017 16:33:54 -0400 Subject:Re: [TUHS] Happy birthday, Dennis Ritchie! What, you didn’t like IBM 2741 terminals that mechanically locked the keyboard? On 2017, Sep 9, at 9:04 AM, William Cheswick <ches at cheswick.com [1]> wrote: Amen. There were a number of things that really sucked at the time. My least favorite: time sharing systems that didn’t allow type-ahead. Kids these days... On 9Sep 2017, at 12:34 AM, Steve Johnson <scj at yaccman.com [2]> wrote: For people used to that world, "echo hello >hi" was literally jaw dropping. Many people had to have it explained twice, because they literally could not conceive of a file being created so easily. I had worked in the computing center for a couple of years, and probably gave more than my share of demos to mainframe users... Steve Links: ------ [1] mailto:ches at cheswick.com [2] mailto:scj at yaccman.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170909/1e8b75db/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-09 21:56 ` Steve Johnson @ 2017-09-10 1:27 ` Dave Horsfall 0 siblings, 0 replies; 204+ messages in thread From: Dave Horsfall @ 2017-09-10 1:27 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 751 bytes --] On Sat, 9 Sep 2017, Steve Johnson wrote: > Part of that problem was probably electronic, not software. Many of > the early terminals were half-duplex. The normal mode was that the > terminal typed what came over the line, and the keyboard was locked. If > you wanted to let the terminal send data, you needed to send a control > character to unlock the keyboard, and then another one to lock it when > you wanted to send data again. Aah, well I remember the times that I felt like leaning over to hit the Big Switch on our 360/50, when the console jammed... That was the Blue Button, of course, not the Red Switch (we weren't allowed to pull that). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-09 20:33 ` Lawrence Stewart 2017-09-09 21:56 ` Steve Johnson @ 2017-09-11 16:20 ` Paul Winalski 1 sibling, 0 replies; 204+ messages in thread From: Paul Winalski @ 2017-09-11 16:20 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 823 bytes --] On 9/9/17, Lawrence Stewart <stewart at serissa.com> wrote: > What, you didn’t like IBM 2741 terminals that mechanically locked the > keyboard? In the business world, these terminals were typically half-duplex and attached 4 or 8 (or more) to a control unit that communicated with the computer using bisynch protocol. It's like a telephone party line--only one terminal can communicate with the computer at a time. The remainder were locked out. [Note that Ethernet works pretty much the same way.] If you wanted to talk to the computer, you pressed the "Request" key. This caused the control unit to send an interrupt to the computer, which in due course would then unlock your terminal and talk to you. This works out OK for transaction processing, but it's not a good fit for interactive time-sharing. -Paul W. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-09 4:34 ` [TUHS] Happy birthday, Dennis Ritchie! Steve Johnson 2017-09-09 13:04 ` William Cheswick @ 2017-09-09 15:55 ` Clem Cole 1 sibling, 0 replies; 204+ messages in thread From: Clem Cole @ 2017-09-09 15:55 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1927 bytes --] below... On Sat, Sep 9, 2017 at 12:34 AM, Steve Johnson <scj at yaccman.com> wrote: > > ... > At the time, the IBM 360 required that you run a special job step to > create a file (we're talking punched cards here). And then you had to pull > that job step out of the deck because trying to create a file that already > existed was an error. > Point taken and sort of...TSS/360 and MTS was not (quite) as bad (although it could be if you use the batch processing system), but Steve is right... the idea of persistence was really not something people considered as 'easy' because it usually cost them money (real or allocated from the computer center). So I suspect part of it was the economics of storage at time. On line (magnetic) storage was way more expensive than cards. Its has been pointed at the the original PDP-7 Ken used did not have a disk on it, it was custom special DEC's CSS group had splicing a PDP-15 disk to it. The disk unit itself was manufactured by someone else (as were most/many of DEC's disks for years). Clay Christensen in "*The Innovator Dilemma" *has curves that actually start a few years later when he studies the disk drive industry. But its the just part of the same effect he is talking about. The key is the what UNIX was doing was not considered practical by the mainframe folks, so people did not consider it. It was a resources to be protected (and to an extent, hoarded maybe). Moore's Law, et al, was the engine that allowed the UNIX innovation to really see light. The way the mainframes were doing things just did not make functional sense, but until it was economical to do it otherwise - we were stuck. As Steve says... it really was mind blowing for making things like this easy. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170909/47feecf7/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-08 21:04 ` Noel Chiappa 2017-09-08 21:09 ` Michael Kjörling @ 2017-09-08 22:28 ` Steve Nickolas 2017-09-09 11:04 ` Michael Kjörling 1 sibling, 1 reply; 204+ messages in thread From: Steve Nickolas @ 2017-09-08 22:28 UTC (permalink / raw) On Fri, 8 Sep 2017, Noel Chiappa wrote: > > From: Dave Horsfall <dave at horsfall.org> > > > Just think, if it wasn't for him and Ken, we'd all be running Windoze, > > and thinking it's wonderful. > > It's actually worse than that. > > We'd be running a Windows even worse than current Windows (which has managed > to pick up a few decent ideas from places like Unix). > > Noel > Heck, even MS-DOS 2 as we knew it would not have been what it was, were it not for Unix. -uso. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-08 22:28 ` Steve Nickolas @ 2017-09-09 11:04 ` Michael Kjörling 2017-09-09 11:19 ` Steve Nickolas 0 siblings, 1 reply; 204+ messages in thread From: Michael Kjörling @ 2017-09-09 11:04 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 658 bytes --] On 8 Sep 2017 18:28 -0400, from usotsuki at buric.co (Steve Nickolas): > Heck, even MS-DOS 2 as we knew it would not have been what it was, > were it not for Unix. Wasn't it MS-DOS 2 that introduced such advanced features as directories, pipes and general console I/O redirection? Of course most software that ran on top of DOS broke much of the redirection niceness by addressing the console directly via video memory access... -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-09 11:04 ` Michael Kjörling @ 2017-09-09 11:19 ` Steve Nickolas 0 siblings, 0 replies; 204+ messages in thread From: Steve Nickolas @ 2017-09-09 11:19 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 884 bytes --] On Sat, 9 Sep 2017, Michael Kjörling wrote: > On 8 Sep 2017 18:28 -0400, from usotsuki at buric.co (Steve Nickolas): >> Heck, even MS-DOS 2 as we knew it would not have been what it was, >> were it not for Unix. > > Wasn't it MS-DOS 2 that introduced such advanced features as > directories, pipes and general console I/O redirection? For varying degrees of "pipes"; it implemented them with a temp file. But yes, and that's exactly what I was referring to - it took those features from Xenix. The API is pretty much as Unixlike as you could get on top of the INT21 interface and on a single-tasking system, I think. > Of course most software that ran on top of DOS broke much of the > redirection niceness by addressing the console directly via video > memory access... Of course. But those kinds of programs often weren't the kind you'd want to redirect anyway. -uso. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-08 20:54 [TUHS] Happy birthday, Dennis Ritchie! Dave Horsfall 2017-09-08 21:04 ` Noel Chiappa @ 2017-09-08 21:05 ` Arthur Krewat 2017-09-08 21:14 ` William Pechter 2017-09-10 9:44 ` [TUHS] Happy birthday, Dennis Ritchie! arnold 3 siblings, 0 replies; 204+ messages in thread From: Arthur Krewat @ 2017-09-08 21:05 UTC (permalink / raw) Seconded. Who knows, may we wouldn't even have Windows. On 9/8/2017 4:54 PM, Dave Horsfall wrote: > Sadly no longer with us (he exited in 2011), he was forked in 1941. > Just think, if it wasn't for him and Ken, we'd all be running Windoze, > and thinking it's wonderful. > > A Unix bigot through and through, I remain, > ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-08 20:54 [TUHS] Happy birthday, Dennis Ritchie! Dave Horsfall 2017-09-08 21:04 ` Noel Chiappa 2017-09-08 21:05 ` Arthur Krewat @ 2017-09-08 21:14 ` William Pechter 2017-09-08 22:13 ` Angus Robinson ` (2 more replies) 2017-09-10 9:44 ` [TUHS] Happy birthday, Dennis Ritchie! arnold 3 siblings, 3 replies; 204+ messages in thread From: William Pechter @ 2017-09-08 21:14 UTC (permalink / raw) If it wasn't for Unix, it possibly would have been VMS on Alpha... Or OS/2. Early Windows 3.x wouldn't have cut it. Perhaps without the Unix workstations DEC might have survived. Interesting alternate history... Bill -----Original Message----- From: Dave Horsfall <dave@horsfall.org> To: The Eunuchs Hysterical Society <tuhs at tuhs.org> Sent: Fri, 08 Sep 2017 16:56 Subject: [TUHS] Happy birthday, Dennis Ritchie! Sadly no longer with us (he exited in 2011), he was forked in 1941. Just think, if it wasn't for him and Ken, we'd all be running Windoze, and thinking it's wonderful. A Unix bigot through and through, I remain, -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-08 21:14 ` William Pechter @ 2017-09-08 22:13 ` Angus Robinson 2017-09-08 23:11 ` William Pechter 2017-09-09 4:20 ` Dave Horsfall 2017-09-11 16:30 ` Paul Winalski 2 siblings, 1 reply; 204+ messages in thread From: Angus Robinson @ 2017-09-08 22:13 UTC (permalink / raw) You also would have Mac OS, Linux,etc On Fri, Sep 8, 2017 at 5:14 PM William Pechter <pechter at gmail.com> wrote: > If it wasn't for Unix, it possibly would have been VMS on Alpha... Or > OS/2. Early Windows 3.x wouldn't have cut it. > > Perhaps without the Unix workstations DEC might have survived. > > Interesting alternate history... > > Bill > > > -----Original Message----- > From: Dave Horsfall <dave at horsfall.org> > To: The Eunuchs Hysterical Society <tuhs at tuhs.org> > Sent: Fri, 08 Sep 2017 16:56 > Subject: [TUHS] Happy birthday, Dennis Ritchie! > > Sadly no longer with us (he exited in 2011), he was forked in 1941. Just > think, if it wasn't for him and Ken, we'd all be running Windoze, and > thinking it's wonderful. > > A Unix bigot through and through, I remain, > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will > suffer." > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170908/c69f8a31/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-08 22:13 ` Angus Robinson @ 2017-09-08 23:11 ` William Pechter 2017-09-09 5:13 ` Dave Horsfall 0 siblings, 1 reply; 204+ messages in thread From: William Pechter @ 2017-09-08 23:11 UTC (permalink / raw) If no Unix... No Mac OSx or Linux or *BSD. Linux came from the Posix spec. OSx came from a Unix personality on Mach... Perhaps the Prime OS or perhaps Domain OS from Apollo would have been the workstation of the tech world. Apollo had a lead on Sun back in the day. Bill Bill -----Original Message----- From: Angus Robinson <angus@fairhaven.za.net> To: William Pechter <pechter at gmail.com>, The Eunuchs Hysterical Society <tuhs at tuhs.org>, Dave Horsfall <dave at horsfall.org> Sent: Fri, 08 Sep 2017 18:14 Subject: Re: [TUHS] Happy birthday, Dennis Ritchie! You also would have Mac OS, Linux,etc On Fri, Sep 8, 2017 at 5:14 PM William Pechter <pechter at gmail.com> wrote: > If it wasn't for Unix, it possibly would have been VMS on Alpha... Or > OS/2. Early Windows 3.x wouldn't have cut it. > > Perhaps without the Unix workstations DEC might have survived. > > Interesting alternate history... > > Bill > > > -----Original Message----- > From: Dave Horsfall <dave at horsfall.org> > To: The Eunuchs Hysterical Society <tuhs at tuhs.org> > Sent: Fri, 08 Sep 2017 16:56 > Subject: [TUHS] Happy birthday, Dennis Ritchie! > > Sadly no longer with us (he exited in 2011), he was forked in 1941. Just > think, if it wasn't for him and Ken, we'd all be running Windoze, and > thinking it's wonderful. > > A Unix bigot through and through, I remain, > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will > suffer." > ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-08 23:11 ` William Pechter @ 2017-09-09 5:13 ` Dave Horsfall 2017-09-09 15:41 ` Larry McVoy 0 siblings, 1 reply; 204+ messages in thread From: Dave Horsfall @ 2017-09-09 5:13 UTC (permalink / raw) On Fri, 8 Sep 2017, William Pechter wrote: > Perhaps the Prime OS or perhaps Domain OS from Apollo would have been > the workstation of the tech world. I almost worked for Pr1me once (I worked next door to them in North Sydney); what stopped me was their notion that "1" was a prime number (yes, I'm a mathematician)... > Apollo had a lead on Sun back in the day. I used to work for Sun, and we hated Apollo :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-09 5:13 ` Dave Horsfall @ 2017-09-09 15:41 ` Larry McVoy 0 siblings, 0 replies; 204+ messages in thread From: Larry McVoy @ 2017-09-09 15:41 UTC (permalink / raw) On Sat, Sep 09, 2017 at 03:13:30PM +1000, Dave Horsfall wrote: > On Fri, 8 Sep 2017, William Pechter wrote: > > >Perhaps the Prime OS or perhaps Domain OS from Apollo would have been the > >workstation of the tech world. > > I almost worked for Pr1me once (I worked next door to them in North Sydney); > what stopped me was their notion that "1" was a prime number (yes, I'm a > mathematician)... > > >Apollo had a lead on Sun back in the day. > > I used to work for Sun, and we hated Apollo :-) Mr Yacc might like this story. Before I worked for Sun I worked for Lachman (porting Unix to the ETA-10) and the dev environment there was apollos served by a Sun 3/280 file server. I was fresh out of school, interviewed with Lachman for this job, they sort of let me believe I'd be doing the VM system for this weird ass machine that was basically a cluster with a huge (at the time) 2GB "shared" memory that was bcopy only. Seemed like a fun project. I got there and they said "Um, you know, we have someone with more than zero years of experience working on the VM system. How about you port all the commands?" Crushed me was like "Really?" They said "Really". Sigh, whatever. So what I quickly learned was weird about this machine was that native pointers pointed at bits. The compiler writers were all like "fuck that, we point at bytes" but they had to have a way to get to real pointers so they decided that if you did char *p = &whatever; int i = (int)p; the assignment of a pointer into an int did the shift to point at the first bit of that byte, and the other way shifted the other way. Got it? Ints held "real" pointers and pointers held byte aligned pointers. It was weird, yes. The unfortunate side effect is that char *p = malloc(10); caused a shift if you didn't include malloc.h. Because the compiler thought malloc was returning a bit pointer so it "kindly" did the shift for us. This quickly became a pattern. Here is what I did: First, and this is the apollo part, I ported the cross compiler from the apollo environment to SunOS. Because compiling on the file server was faster in two ways: (a) local file system instead of NFS and (b) the Sun was way way faster than those stupid apollo machines. And the Sun was real Unix. The port caused all sorts of fuss because I wasn't part of the compiler team, I had to write a tool that diffed the binaries produced by the Sun with the ones produced by the apollos to show that the only difference was in the a.out header that had a timestamp or something. Second, and this is the part that Steve might like, I hacked lint suck that when it complained about type mismatches it wandered around until it got to the base types and printed out type mismatch: "INT" vs "POINTER" which wasn't that easy, I didn't really understand the guts of lint. I think those changes did wind their way back into Sys V lint somehow, I had nothing to do with it, maybe someone from Lachman fed them back or maybe the Sys V people redid them on their own. OK, so now I lint all of /usr/src/cmd and I wrote an awk script (perl wasn't around yet and awk worked fine) that looked for any int/pointer mismatch, edited the file, and included every header I could think of that declared some library function that returned a pointer, string.h, malloc.h, etc. I iterated a few times (this was an overnight thing, I'd come in in the morning and see that I forgot some more, add them to the list, restart the script). Finally I get a clean lint run and I start up a compile run, fix up a few remaining things (there were surprisingly few, it was an easy port) and I've got a built /usr/src/cmd installed on piper1, my test machine. I go to my boss and say "I'm done". Note that all of this stuff, getting onboarded, porting the compiler, wacking lint, linting, compiling, took about 3 weeks. I was a busy little beaver :) My boss goes "yeah, right. Hey, Mike, go look at piper1 and see what kind of a mess we have". Mike goes off and comes back, gives me a weird look, and says "He's right, he's done". Sort of, we didn't have tty's yet so vi didn't work, we didn't have a kmem driver so ps didn't work (which was *really* annoying), etc. But awk worked, find worked, ls worked, all that stuff worked. My boss says "get out of here, let me think about this". I come back in the next day, go to my boss (Bob Palm if any of you know him, great guy) and he says "You can go home, we'll just pay you". Turns out that Lachman had budgeted for 6 months to do the /usr/src/cmd port and it didn't look good to have me sitting around doing nothing. I, being the nerd that I am, said "Do you mind if I stick around if I'm doing work?" Bob says "Go for it, you can do whatever you want if you look busy". And there began the most awesome 6 months of my life. I wrote my own version of ps and a /dev/ps driver that was a dumbed down version of /dev/kmem, because I was too clueless to write a kmem driver. People used that ps for a long time until someone did a real kmem driver. I wrote the Unix side of the disk driver, which sounds hard but wasn't, this thing had I/O channels that had their own processor so it was more like writing a http client or something, just in the kernel. The real driver was in the I/O channel, all I had to do was learn how to talk to the I/O channel. And it was a polling driver, no interrupts, there was some hardware glitch with interrupts or something, whatever the reason, I just polled so it was easy. Shitty perf but easy. I ported all of the Lachman STREAMS TCP stack. If I recall correctly shorts weren't shorts, they were u32. So all the unsigned short port; became unsigned short port:16; I remember the stack being the biggest job, there were some things that turned out to be tricky, long forgotten. Oh, I bet anything a lot of it was the networking drivers. I know some of it was me banging on stuff but I think there were some driver issues as well, I didn't work on those, I'm not much of a device driver person. After all this I got sent to Japan with 3 source tapes, the base system that included all of /usr/src/cmd and everyone else's stuff that had sort of been approved for integration, a version of the tree with big pages, and the version of the tree that had the networking stack in it. I was sent to the Tokyo Institute of Technology (TIT) and I was the techy guy, they sent me with another Sun 3/280 and two Sun 3/50 (screw that apollo crud) and told me to set up a dev environment and merge those source trees. So of course the server was installed as "bigtit" and the 3/50's as "lefttit" and "righttit" which lasted until the Japanese folks figured out what those meant. I was there for 3 months, doing the merge wasn't easy and then other problems cropped, again with the drivers if I remember correctly. So the folks back in St Paul were sending me stuff, I was merging it, building, installing, testing, reporting back what didn't work, and that went on for quite a while. Eventually it worked and home I went. Lost a bunch of weight because I didn't like sushi at the time and there weren't a lot of good alternatives that kept my weight up. Fun times. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-08 21:14 ` William Pechter 2017-09-08 22:13 ` Angus Robinson @ 2017-09-09 4:20 ` Dave Horsfall 2017-09-11 16:30 ` Paul Winalski 2 siblings, 0 replies; 204+ messages in thread From: Dave Horsfall @ 2017-09-09 4:20 UTC (permalink / raw) On Fri, 8 Sep 2017, William Pechter wrote: > Perhaps without the Unix workstations DEC might have survived. Sigh :-) RSTS, RSX-11[MD], Pick, VMS, etc; they've all taken on Unix, and I've been privileged to see them all off :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-08 21:14 ` William Pechter 2017-09-08 22:13 ` Angus Robinson 2017-09-09 4:20 ` Dave Horsfall @ 2017-09-11 16:30 ` Paul Winalski 2017-09-11 16:49 ` [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo ] Jon Steinhart 2 siblings, 1 reply; 204+ messages in thread From: Paul Winalski @ 2017-09-11 16:30 UTC (permalink / raw) On 9/8/17, William Pechter <pechter at gmail.com> wrote: > If it wasn't for Unix, it possibly would have been VMS on Alpha... Or OS/2. > Early Windows 3.x wouldn't have cut it. > > Perhaps without the Unix workstations DEC might have survived. > > Interesting alternate history... Clem Cole and I could go on for pages on why DEC went out of business. But it's pretty much off-topic for this list. SUN captured the workstation market from Apollo and DEC because they managed to sell workstations cheaper than their competitors. I don't think that the OS being UNIX had very much to do with it. But using UNIX probably lowered SUN's software development costs, and no doubt that contributed to their lower workstation cost. What ultimately did in DEC was missing the PC wave. PCs did the same thing to the minicomputer and workstation companies that minicomputers did to mainframes in the 1970s. PCs offered equivalent (or better) capabilities at much reduced cost. First they ate the word processor market (remember Wang?) and then minicomputers and workstations. UNIX workstation manufacturers such as SUN suffered the same fate as DEC at the hands of the PC. UNIX did not save them. -Paul W. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo ] 2017-09-11 16:30 ` Paul Winalski @ 2017-09-11 16:49 ` Jon Steinhart 2017-09-11 17:37 ` Paul Winalski 2017-09-11 23:09 ` Larry McVoy 0 siblings, 2 replies; 204+ messages in thread From: Jon Steinhart @ 2017-09-11 16:49 UTC (permalink / raw) Paul Winalski writes: > SUN captured the workstation market from Apollo and DEC because they > managed to sell workstations cheaper than their competitors. I don't > think that the OS being UNIX had very much to do with it. But using > UNIX probably lowered SUN's software development costs, and no doubt > that contributed to their lower workstation cost. While the choice of UNIX may have played a small part, Sun really nailed it with the SparcStation I. Sure, they sold it for less than whatever the DEC equivalent was at the time, but that's because their manufacturing cost was way less. The SparcStation I pioneered a lot of new manufacturing technology; it was the first snap-together system. I remember looking at a tear-down of the DEC and Sun offerings, and the Sun had less than 10% of the parts of the equivalent DEC system. Methinks that better engineering won the day. Jon ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo ] 2017-09-11 16:49 ` [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo ] Jon Steinhart @ 2017-09-11 17:37 ` Paul Winalski 2017-09-11 23:09 ` Larry McVoy 1 sibling, 0 replies; 204+ messages in thread From: Paul Winalski @ 2017-09-11 17:37 UTC (permalink / raw) On 9/11/17, Jon Steinhart <jon at fourwinds.com> wrote: > > While the choice of UNIX may have played a small part, Sun really nailed > it with the SparcStation I. Sure, they sold it for less than whatever > the DEC equivalent was at the time, but that's because their manufacturing > cost was way less. The SparcStation I pioneered a lot of new manufacturing > technology; it was the first snap-together system. I remember looking at > a tear-down of the DEC and Sun offerings, and the Sun had less than 10% of > the parts of the equivalent DEC system. Methinks that better engineering > won the day. Absolutely. I worked at DEC and had many engineer friends at Apollo, and we were all shaking our heads wondering how Sun got their manufacturing costs so low. Scott McNealy's management style helped, too. Ken Olsen at DEC believed in consensus building; decisions weren't final until everyone bought into them. IMO this led to a lot of (expensive) wrangling and slowed down corporate reaction to market conditions. Scott McNealy believed in the principle of a single decision-maker: "lead, follow, or get out of the way". We at DEC eventually moved to project management that involved a single lead engineer who was responsible for the success of the project, and who was empowered to make decisions when a consensus couldn't be found. But that management style never really caught on, although in my experience the most successful software projects were all organized that way. -Paul W. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo ] 2017-09-11 16:49 ` [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo ] Jon Steinhart 2017-09-11 17:37 ` Paul Winalski @ 2017-09-11 23:09 ` Larry McVoy 2017-09-12 7:38 ` arnold 1 sibling, 1 reply; 204+ messages in thread From: Larry McVoy @ 2017-09-11 23:09 UTC (permalink / raw) On Mon, Sep 11, 2017 at 09:49:16AM -0700, Jon Steinhart wrote: > Paul Winalski writes: > > SUN captured the workstation market from Apollo and DEC because they > > managed to sell workstations cheaper than their competitors. I don't > > think that the OS being UNIX had very much to do with it. But using > > UNIX probably lowered SUN's software development costs, and no doubt > > that contributed to their lower workstation cost. > > While the choice of UNIX may have played a small part, Sun really nailed > it with the SparcStation I. Sure, they sold it for less than whatever > the DEC equivalent was at the time, but that's because their manufacturing > cost was way less. The SparcStation I pioneered a lot of new manufacturing > technology; it was the first snap-together system. I remember looking at > a tear-down of the DEC and Sun offerings, and the Sun had less than 10% of > the parts of the equivalent DEC system. Methinks that better engineering > won the day. And don't underestimate the draw of a BSD that was "fixed", had mmap that worked, unified page cache, VFS layer that was pleasant. I worked for Lachman before I worked for Sun, saw the guts of quite a few Unix OS's. SunOS was by *far* the most pleasant and well thought out. It was an OS where you could predict what it would do based on the architecture and sure enough, that's what it did. I miss that source base. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo ] 2017-09-11 23:09 ` Larry McVoy @ 2017-09-12 7:38 ` arnold 2017-09-12 14:12 ` Ronald Natalie 2017-09-12 15:35 ` [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] Jon Steinhart 0 siblings, 2 replies; 204+ messages in thread From: arnold @ 2017-09-12 7:38 UTC (permalink / raw) Larry McVoy <lm at mcvoy.com> wrote: > And don't underestimate the draw of a BSD that was "fixed", had mmap that > worked, unified page cache, VFS layer that was pleasant. I worked for > Lachman before I worked for Sun, saw the guts of quite a few Unix OS's. > SunOS was by *far* the most pleasant and well thought out. It was an > OS where you could predict what it would do based on the architecture > and sure enough, that's what it did. Thinking about it, particularly in light of the fact that Oracle has finally killed Solaris, it seems to me that another reason that Sun succeeded was that they were the ones who really innovated. In particular, the creation of NFS and then the efforts to make it into a de-facto standard (giving away the RPC and XDR code) was a HUGE thing. They weren't afraid to swim upstream, either. Even though NeWS never took off (even when combined with an X server), it was an interesting design, ahead of its time even. They were the first of the major Unix vendors to really dive into RISC, if I recall correctly. MIPS may have been the first Unix vendor based on a RISC architecture, but they were a startup. DEC, IBM, and HP, all seemed to be playing follow the leader to Sun for many years. My two cents, as filtered through my aging memory, (:-) Arnold ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo ] 2017-09-12 7:38 ` arnold @ 2017-09-12 14:12 ` Ronald Natalie 2017-09-12 14:51 ` Toby Thain 2017-09-12 15:33 ` arnold 2017-09-12 15:35 ` [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] Jon Steinhart 1 sibling, 2 replies; 204+ messages in thread From: Ronald Natalie @ 2017-09-12 14:12 UTC (permalink / raw) > > They weren't afraid to swim upstream, either. Even though NeWS never took > off (even when combined with an X server), it was an interesting design, > ahead of its time even. > > NeWS had serious issues. However, the same guy who was the NeWS proponent learned from mistakes and the result was the must more successful Sun tehnology: JAVA. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo ] 2017-09-12 14:12 ` Ronald Natalie @ 2017-09-12 14:51 ` Toby Thain 2017-09-12 15:33 ` arnold 1 sibling, 0 replies; 204+ messages in thread From: Toby Thain @ 2017-09-12 14:51 UTC (permalink / raw) On 2017-09-12 10:12 AM, Ronald Natalie wrote: > >> >> They weren't afraid to swim upstream, either. Even though NeWS never took >> off (even when combined with an X server), it was an interesting design, >> ahead of its time even. >> >> > NeWS had serious issues. However, the same guy who was the NeWS proponent learned from mistakes and the result > was the must more successful Sun tehnology: JAVA. > > It would probably befit this list and posterity to go into detail about what those issues were. At the time, NeWS certainly seemed to have interesting ideas far ahead of the popular window systems (and yes we could discuss those ideas as well. Unfortunately my NeWS developer binder is in storage and my memory isn't reliable at that range). --T ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo ] 2017-09-12 14:12 ` Ronald Natalie 2017-09-12 14:51 ` Toby Thain @ 2017-09-12 15:33 ` arnold 1 sibling, 0 replies; 204+ messages in thread From: arnold @ 2017-09-12 15:33 UTC (permalink / raw) Ronald Natalie <ron at ronnatalie.com> wrote: > > > > > They weren't afraid to swim upstream, either. Even though NeWS never took > > off (even when combined with an X server), it was an interesting design, > > ahead of its time even. > > > > > NeWS had serious issues. However, the same guy who was the NeWS proponent learned from mistakes and the result > was the must more successful Sun tehnology: JAVA. > But you have strengthened my main point, which is that Sun *innovated*. NFS, NeWS, Java - 2 out of 3 is pretty good. :-) Thanks, Arnold ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-12 7:38 ` arnold 2017-09-12 14:12 ` Ronald Natalie @ 2017-09-12 15:35 ` Jon Steinhart 2017-09-12 16:57 ` Larry McVoy ` (2 more replies) 1 sibling, 3 replies; 204+ messages in thread From: Jon Steinhart @ 2017-09-12 15:35 UTC (permalink / raw) arnold at skeeve.com writes: > > In particular, the creation of NFS and then the efforts to make it into > a de-facto standard (giving away the RPC and XDR code) was a HUGE thing. > > They weren't afraid to swim upstream, either. Even though NeWS never took > off (even when combined with an X server), it was an interesting design, > ahead of its time even. It's interesting that you mention the two of these together. It's my opinion that the main reason that NeWS failed was because of the success of NFS. I recall that Apollo was really pissed off by NFS because they felt that their token-ring network was better but lost because NFS was given away. In hindsight, they were wrong; while the token-ring performed better in large networks, the advent of switches made that moot. In any case, when NeWS was released nobody except Sun knew how to do the graphics (even Adobe didn't know how to do it fast for display) and Apollo et. al. was worried that Sun would give NeWS away and make it yet another de facto standard a la NFS. This led to the formation of the Hamilton Group which was a thinly-disguised industry consortium that existed only for the purpose of making sure that NeWS didn't succeed. > DEC, IBM, and HP, all seemed to be playing follow the leader to Sun for > many years. I mentioned this to a lot of people after Sun died. Few seem to realize how much of what became PC manufacturing technology resulted from innovations at Sun. ron at ronnatalie.com writes: > > NeWS had serious issues. However, the same guy who was the NeWS proponent > learned from mistakes and the result was the must more successful Sun > tehnology: JAVA. I'm going to take issue with the above. NeWS had way fewer serious issues than X. It's main reason for failure was the coordinated effort to kill it from others in the industry. As the guy who single-handedly prevented X from becoming an ANSI standard, I'd be happy to start another thread on this topic if people are interested. Part of the result of the Hamilton Group effort was the misguided attempt to merge X and NeWS which was a botched disaster. Java is not the result of learning from mistakes in NeWS. I have joked with James that I feel that his legacy is being the person who first realizes that technology is changing to the point where something can be done using an interpreter. If you look at his project history, he's done this many times. I think that it's more accurate to say that Java is the result of a lifetime of learning from interpreter projects. I fully expect some new interpreter to take over AWS sometime soon :-) Jon ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-12 15:35 ` [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] Jon Steinhart @ 2017-09-12 16:57 ` Larry McVoy 2017-09-12 17:04 ` Arthur Krewat 2017-09-12 20:15 ` Steve Johnson 2 siblings, 0 replies; 204+ messages in thread From: Larry McVoy @ 2017-09-12 16:57 UTC (permalink / raw) On Tue, Sep 12, 2017 at 08:35:24AM -0700, Jon Steinhart wrote: > arnold at skeeve.com writes: > > > > In particular, the creation of NFS and then the efforts to make it into > > a de-facto standard (giving away the RPC and XDR code) was a HUGE thing. > > > > They weren't afraid to swim upstream, either. Even though NeWS never took > > off (even when combined with an X server), it was an interesting design, > > ahead of its time even. > > It's interesting that you mention the two of these together. It's my > opinion that the main reason that NeWS failed was because of the success > of NFS. > > I recall that Apollo was really pissed off by NFS because they felt that > their token-ring network was better but lost because NFS was given away. > In hindsight, they were wrong; while the token-ring performed better in > large networks, the advent of switches made that moot. In any case, when > NeWS was released nobody except Sun knew how to do the graphics (even > Adobe didn't know how to do it fast for display) and Apollo et. al. was > worried that Sun would give NeWS away and make it yet another de facto > standard a la NFS. This led to the formation of the Hamilton Group which > was a thinly-disguised industry consortium that existed only for the > purpose of making sure that NeWS didn't succeed. It was more than NeWS, it was anything Sun. Here's how 100Mbit ethernet happened because of Sun (well, really me and Andy) in spite of the "anything but Sun sentiment": Some background to go with what Jon said. I was at Sun during this time, Sun was on a roll, they kept innovating and other people were playing catchup, mmap, vm layer that worked, VFS interface that worked, NFS, etc. Sun really was innovating back then and it left other people behind and pissed. They were especially pissed when Sun stuff became a standard and they had to match it. So they formed a loose cabal that had the sentiment of "No more Sun wins". At the time I was arguing for 100Mbit ethernet with little success. The hardware guys hadn't twigged to the idea that one base packet format over a bunch of different speed cables is better than multiple packet types that you have to rewrite. When I asked for 100mbit over copper they said it couldn't be done. I was a systems guy at the time, building a clustered NFS server code named sunbox. Venders were constantly coming to me to pitch their stuff to be included in my system (we did use Kalpana switches so one of the pitches worked). One day some dude from Crescendo shows up with a pitch for something they called CDDI. It was FDDI over copper at 100mbit. I said wait here, went down the hall to Andy Bechtolsheim's office (I had the good fortune to have an office next door to him, a little brag, but I was living the dream!) got Andy and dragged him back to the meeting. Asked the dude to do it again. We thanked him and went back to our offices and I ask Andy "You thinking what I'm thinking" because he knew about my 100Mbit ethernet dreams. "Yeah, but there is the cabal problem". We knew about the anti Sun sentiment, wasn't much we could do about it, it was just a problem we had to route around. So what we did is a little road show in the valley. The Crescendo guys hadn't made us sign an NDA, their stuff was for sale already. So we went to every hardware company in the valley that made network cards and said "Did you know these guys are signalling at 100Mbit over copper? Wouldn't it be cool if you made an ethernet card that did that?". That was all it took, someone had a card about 6 months later and the rest is history. I'm sure it would have happened by itself at some point, but Sun made that stuff happen as well. They really were on a roll back then and in the hardware side it was all Andy. He was in his sweet spot which is anything that he can keep the whole picture, all the details, in his head. He's fantastic at that. There is a story, no idea if it is true but it sounds like Andy, that someone interrupted a meeting to tell him that the serial chip was going to be like a buck or so cheaper. There is this brief pause and then Andy says "Cool, we'll use it for more pigment in the feet, I was wondering where that would come from." Fun times for sure! I'm super super lucky to have been there and been a part of it. It wasn't Bell Labs when Dennis and Ken and team were making Unix, I would have loved to have been there but wrong age. Sun was the Bell Labs of their time. I fought hard to get in there and once I was in it was awesome. Yeah, there were politics and all the usual stuff, but I knew I was at the place that was leading and I got to be part of it. Living the dream for sure. --lm ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-12 15:35 ` [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] Jon Steinhart 2017-09-12 16:57 ` Larry McVoy @ 2017-09-12 17:04 ` Arthur Krewat 2017-09-12 17:07 ` Larry McVoy ` (2 more replies) 2017-09-12 20:15 ` Steve Johnson 2 siblings, 3 replies; 204+ messages in thread From: Arthur Krewat @ 2017-09-12 17:04 UTC (permalink / raw) Oh, do, please go on ;) On 9/12/2017 11:35 AM, Jon Steinhart wrote: > As the guy who single-handedly prevented X > from becoming an ANSI standard, I'd be happy to start another thread on > this topic if people are interested. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-12 17:04 ` Arthur Krewat @ 2017-09-12 17:07 ` Larry McVoy 2017-09-12 22:11 ` [TUHS] X and NeWS history (long) Jon Steinhart 2017-09-12 23:33 ` [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] Dave Horsfall 2 siblings, 0 replies; 204+ messages in thread From: Larry McVoy @ 2017-09-12 17:07 UTC (permalink / raw) I'd like to hear that too. I like X11, use it all the time, take advantage of the remote display all the time, have done some sunview programming and a little of just the base libraries. I can imagine that standardizing all that stuff would be more than a mouthful. But what else ya got? On Tue, Sep 12, 2017 at 01:04:30PM -0400, Arthur Krewat wrote: > Oh, do, please go on ;) > > > > On 9/12/2017 11:35 AM, Jon Steinhart wrote: > >As the guy who single-handedly prevented X > >from becoming an ANSI standard, I'd be happy to start another thread on > >this topic if people are interested. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-12 17:04 ` Arthur Krewat 2017-09-12 17:07 ` Larry McVoy @ 2017-09-12 22:11 ` Jon Steinhart 2017-09-12 22:58 ` Larry McVoy ` (3 more replies) 2017-09-12 23:33 ` [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] Dave Horsfall 2 siblings, 4 replies; 204+ messages in thread From: Jon Steinhart @ 2017-09-12 22:11 UTC (permalink / raw) > Jon Steinhart wrote: > As the guy who single-handedly prevented X from becoming an ANSI standard, > I'd be happy to start another thread on this topic if people are interested. Arthur Krewat writes: > Oh, do, please go on ;) Larry McVoy writes: > I'd like to hear that too. I like X11, use it all the time, take advantage > of the remote display all the time, have done some sunview programming and > a little of just the base libraries. I can imagine that standardizing all > that stuff would be more than a mouthful. But what else ya got? OK, you asked for it. I think that I need to ask the Thing King to zark in a few crates of old memories... I spent mt teenage years as a graphics person as a result of my summer job at Murray Hill working on the Glance-G terminal project. Side-tracked into test and measurement after getting my EE degree and doing cool black magic electronics at Tektronix. Got back into graphics and software when Tek tried to get into the UNIX workstation business. Started working on window systems at that time, and continued after I quit Tek and moved to the bay area to play at the startup game. Started consulting after the third startup failed which I'm still doing today. While at Tek one of my jobs was to come up with a C language binding for GKS, the Graphical Kernel System standard. That itself is a funny story which ties into the earlier troff thread. I designed a language binding and wrote it up. My friend Ed, author of "Real Programmers Don't Use Pascal", worked down the road at GSS (Graphics Software Systems). He told me that "yours looks better than ours, you should bring it to the standards committee". Amazingly enough my management bought off on it, I brought my draft to the Huntsville meeting, and it was adopted as the draft standard. Why? Because we had troff and an Imprint-10! Those were the days when people equated typeset with professional. I recall discussing the issues with the C binding at an ANSI C committee meeting in San Franscisco; probably met some you there. ANSI X3X3 formed a window management subcommittee X3H3.6 somewhere along the line. I moved over there as I was pretty much done with the GKS stuff and the window management end of things was more interesting. Life changed in that committee when the X push happened. But first, a bit on a parallel track. I knew Keith Lantz at Stanford who, if I remember correctly, had a graduate seminar and wanted to talk about window management systems. I came in as a guest lecturer. Partly because of this I became aware of the origins of X as those weren't the days when one could easily just get technical papers on line. For those of you unfamiliar with this, Stanford had developed the V operating system which featured very fast synchronous IPC. I believe that this ran on the original Stanford University Network (SUN) boards. They also developed the W window system which ran on top of V. I'm a bit fuzzy on the continental shift, but I believe that W made the cross country trip to MIT via some sort of DEC connection. Maybe they had funded some of the Stanford research. Gosling and Rosenthal had been working on the Andrew window system at CMU. I don't remember whether or not this was UNIX-based, but one of their early design decisions was to minimize round-trips because they didn't have fast synchronous IPC. Despite this prior art, Scheifler took the W code, ported it to UNIX, and called it X. As one would expect, the performance was terrible. X got stuck at this state, version 10, for a long time. Sun announced NeWS during this stagnant period. Freaked out Apollo, DEC, HP, etc. who got together at DEC's Hamilton Avenue building to plot the "anything but Sun" strategy. They were successful in holding off the adoption of NeWS until they could rewrite X to eliminate many of the synchronous round trips from the protocol resulting in X version 11 which was pretty much completely incompatible with version 10. In many respects Sun botched NeWS politically. Large numbers of businesses relied on applications that ran on Sun's SunView window system which was heavily hooked into the OS and not even remotely portable. They couldn't use NeWS instead of SunView because they were running real businesses. There was no way to run SunView and NeWS at the same time so businesses couldn't run new NeWS-based applications and old SunView applications at the same time. I'm a bit fuzzy here, but the decision to merge X and NeWS was a bad technical solution to a political problem. Sun wanted to be able to say "We have X too." Unfortunately, folks at Sun agreed to do this project without knowing what they were talking about; it got rough when they realized that the NeWS and X graphics models were completely incompatible. Oh, despite all of the hype, there was actually nothing useful that one could do using X at the time. Not being very well socially adjusted, I annoyed a lot of people by going to show floors and looking at X running things like maze and loudly proclaiming "Oh, that's exactly what I do for a living." Somewhere along the line Sun also decided to produce a mostly automated system to convert SunView programs to use X. I think that this was called XView. I remember billing for many a late night to actually get the thing working. One of my other clients at the time was AED (advanced electronic displays). If you were lucky enough to have a color frame buffer in those days it was likely one of theirs. They had a project to build X accelerator boards that plugged into Sun workstations. I think that I got called in because it wouldn't work on the 3/260 which I eventually tracked down to the behavior of the cache that only the 260 had. AED was trying to figure out what to do as the world had changed and frame buffers couldn't compete with workstations. I came up with the idea to make an X server that would run in a SunView window so that companies that relied on SunView applications could run X applications concurrently. We called this XTool in keeping with the SunView application naming scheme. I think that I still have a few "XTool - Safe X for Suns" tee shirts around somewhere. This project unfortunately failed because AED was bought by someone with a "ship it now, that'll force folks to fix the bugs" attitude. XTool was very small and fast compared to the X sample server because I wrote the server from scratch. I think that I'm the only person to write an X server outside of the X Consortium. One of the things that I learned by doing it was that the X Consortium folks were wrong when they said that the documentation was the standard, not the sample server. There were significant differences between the two. We showed XTool off at some shows. People would come by the booth and ask "how did you get it to run so fast?" Being me, I loudly answered "We cheated. We designed ours first." Turns out that one of these times Keith Packard and Jim Gettys were walking by which resulted in some long-standing animosity. Back to the standards track. Any of you that have done ANSI work know that CBEMA has a one organization, one vote policy. When Scheifler showed up at X3H3.6 all other work stopped and X became a draft standard. Whenever there was a vote everybody would look to see how Bob was voting and voted with him. For political reasons, all of the voting members from X Consortium member companies had been told that they couldn't vote against X for technical reasons. You may also know that one has to pay to be on an ANSI committee. I wrote the ANSI Secretariet and told them that I felt that by having both the X Consortium and their member companies voting violated the spirit of the one organization one vote rule, and that I couldn't justify continuing to pay to be on the committee with this behavior. They took it under advisement. Eventually, public review time came around. I submitted a document containing something on the order of 800 comments. These were pretty repetitious because I had to hit the document one request at a time, but the major themes were: o The only really worthwhile thing about X was the distributed extension registration mechanism. All of the input, graphics and other crap should be moved to extension #1. That way, it won't be mandatory in conforming implementations once that stuff was obsolete. As you probably know, that's where we are today; nobody uses that stuff but it's like the corner of an Intel chip that implements the original instruction set. As an aside, I upset many when working on OpenDoc for Apple and saying the same thing there. o The atom/property mechanism allows clients to allocate memory in the server that can never be freed. Some way to free memory needs to be added. o The bit encodings should be part of a separate language binding, not part of the functional description. I received a reply from the committee that said "Thank you for you comments." I wrote the ANSI Secretariet and asked "Don't the rules for milestone 9 say that the technical committee must make all reasonable efforts to accomodate public review comments?" The Secretariet wrote the committee. Everybody on the committee from companies such as Sun who had bee prohibited from voting no for technical reasons all jumped up and cried "procedural violation" and voted against forwarding the standard. Scheifler stormed out. I heard later than Scheifler wrote an angry letter to the Secretariet saying "how dare you listen to that one lone consultant when I have the backing of all of these major companies?" The response was "Didn't you read our rules before joining?" Of course, by the time all of this settled out X was entrenched setting back the state of UNIX UI for a long time. A couple of decades ago I bough a Sun Ultra-60 and asked whether it was worth paying for the dual processor version. The answer that I got was "Yes. You need one processor to run X and another for everything else." Wrapping this up, I have a section in the book that I'm writing where I talk about how to design a good API. I pose the question of why none of the original Apple Mac API published in 1985 taking about 1,200 pages is in use today whereas almost all of the UNIX V6 API published in 1975 taking 321 pages is still in use and has been copied by many other systems. I'm sure that everyone on this list knows the answer. X suffers from the same problems as the original Mac API. Scheifler et. al. didn't really do any system level design and modelling. I know this because I discussed it with Scheifler at an ANSI meeting in Tulsa, the only place that I have travelled to on business that had no redeeming qualities. He said "I don't believe in models because they predispose the implementation." Had he done some real design work and looked at what others were doing he might have realized that at its core, X was a distributed database system in which operations on some of the databases have visual side-effects. I forget the exact number, but X includes around 20 different databases: atoms, properties, contexts, selections, keymaps, etc. each with their own set of API calls. As a result, the X API is wide and shallow like the Mac, and full of interesting race conditions to boot. The whole thing could have been done with less than a dozen API calls. Wrapping this up on a happy note, some years ago I was hanging out yakking at the Hacker's Conference when this guy I didn't recognize due to hair loss came up to me and said "I'm not going to say that you weren't an asshole because you were, but you were right." It was Keith Packard who was trying to get X running on the OLPC and had run into the issue of clients allocating server memory that couldn't be freed. Been good friends since. Same with Gettys. Well, that's the whole sordid take from my point of view. Hope that you enjoyed it. Jon ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-12 22:11 ` [TUHS] X and NeWS history (long) Jon Steinhart @ 2017-09-12 22:58 ` Larry McVoy 2017-09-12 23:22 ` Jon Steinhart 2017-09-12 23:41 ` Adam Sampson ` (2 subsequent siblings) 3 siblings, 1 reply; 204+ messages in thread From: Larry McVoy @ 2017-09-12 22:58 UTC (permalink / raw) On Tue, Sep 12, 2017 at 03:11:03PM -0700, Jon Steinhart wrote: > In many respects Sun botched NeWS politically. Large numbers of businesses > relied on applications that ran on Sun's SunView window system which was > heavily hooked into the OS and not even remotely portable. The rest of your story is great, just one small correction. SunView started as something Sun specific but it pretty quickly became a library on top of X11. I'm not sure if it ever worked on X10, I think it did but I'm not sure. Source: I've hacked up GUI interfaces for the SCM I did at Sun in Sunview. This would have been around 1990, is that still X10 or X11? > We showed XTool off at some shows. People would come by the booth and ask > "how did you get it to run so fast?" Being me, I loudly answered "We cheated. > We designed ours first." Turns out that one of these times Keith Packard and > Jim Gettys were walking by which resulted in some long-standing animosity. Heh. I can only imagine. ROTFLMAF. > Wrapping this up on a happy note, some years ago I was hanging out yakking at > the Hacker's Conference when this guy I didn't recognize due to hair loss came > up to me and said "I'm not going to say that you weren't an asshole because > you were, but you were right." It was Keith Packard who was trying to get X > running on the OLPC and had run into the issue of clients allocating server > memory that couldn't be freed. Been good friends since. Same with Gettys. Awesome. > Well, that's the whole sordid take from my point of view. Hope that you > enjoyed it. I sure did, love to meet you some time, where are you? --lm ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-12 22:58 ` Larry McVoy @ 2017-09-12 23:22 ` Jon Steinhart 2017-09-12 23:44 ` Chris Torek 0 siblings, 1 reply; 204+ messages in thread From: Jon Steinhart @ 2017-09-12 23:22 UTC (permalink / raw) Larry McVoy writes: > > The rest of your story is great, just one small correction. SunView started > as something Sun specific but it pretty quickly became a library on top of > X11. I'm not sure if it ever worked on X10, I think it did but I'm not sure. > > Source: I've hacked up GUI interfaces for the SCM I did at Sun in Sunview. > This would have been around 1990, is that still X10 or X11? Well, just to nitpick, I remember that much of SunView was a library but it relied on special device drivers with complicated ioctls and such. I don't recall that it be easily separated from the OS. BTW, on a historically amusing note, I still have two old Sun machines in the basement, a SparcStation 20 and an Ultra-60. The 20 has whatever graphics card supported double-buffering. It has a modified kernel thanks to some unnamed (and unremembered at this point) soul who provided source code. I hacked it so that SunView ran in one of the buffers and X ran in the other. Moving the mouse off of the edge of the screen switched which buffer was displayed. My answer to being able to run both SunView and X. > I sure did, love to meet you some time, where are you? I live in Oregon, about 50 miles southwest of Portland. I will probably be in San Francisco the first full weekend of October for the Hardly Strictly Bluegrass Festival if you're in the bay area. Will be staying at Sun employee #5's house. Jon ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-12 23:22 ` Jon Steinhart @ 2017-09-12 23:44 ` Chris Torek 0 siblings, 0 replies; 204+ messages in thread From: Chris Torek @ 2017-09-12 23:44 UTC (permalink / raw) >Well, just to nitpick, I remember that much of SunView was a library but it >relied on special device drivers with complicated ioctls and such. I don't >recall that it be easily separated from the OS. My (fuzzy) memory was that you called library routines to do rasterops, and they consulted with the specific frame buffer hardware in a way that, to (mis)quote Dennis Ritchie, had: unwarranted chumminess with the ... implementation [see http://c-faq.com/struct/structhack.html for actual quote]. This meant if your rasterop was misbehaving, it could be a bug in a driver, or in the hardware. (I remember this from trying to chase down some weird rasterop behavior, or some such.) Chris ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-12 22:11 ` [TUHS] X and NeWS history (long) Jon Steinhart 2017-09-12 22:58 ` Larry McVoy @ 2017-09-12 23:41 ` Adam Sampson 2017-09-13 0:14 ` Jon Steinhart 2017-09-13 0:29 ` [TUHS] X and NeWS history (long) Bakul Shah 2017-09-13 15:09 ` Tony Finch 3 siblings, 1 reply; 204+ messages in thread From: Adam Sampson @ 2017-09-12 23:41 UTC (permalink / raw) Jon Steinhart <jon at fourwinds.com> writes: > I think that I'm the only person to write an X server outside of the X > Consortium. When I was doing my PhD a few years ago, one of the case studies I used was an X11 server that was written in occam 2 by Colin Willcock at the University of Kent at Canterbury. I managed to recover Colin's source code for the X server (in Transputer Development System format), which is dated November 1988, from a very dusty machine backup... I also found the sources for Colin's 1991 report to the funding body on the completion of the project, and his 1992 PhD thesis which describes the same work. I rebuilt these in 2010 using a modern version of TeX, so the appearance is probably different from what Colin intended (and the cover-page dates are definitely wrong), but they're quite readable: https://stuff.offog.org/cw3-report-rebuilt.pdf https://stuff.offog.org/cw3-thesis-rebuilt.pdf Note in particular the motivation stated in the report: "The worst of these problems was the MEiKO C compiler, which (by mid-1988) proved incapable of making any significant headway when presented with the public-domain X-sources. [...] After consultation with the project monitoring officers at RAL, we took the decision to investigate the prospects for a complete re-implementation of the X-server in occam 2, making no use of the public domain C sources." There have of course been other X server implementations more recently, but they're less historically interesting! -- Adam Sampson <ats at offog.org> <http://offog.org/> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-12 23:41 ` Adam Sampson @ 2017-09-13 0:14 ` Jon Steinhart 2017-09-13 16:38 ` [TUHS] old X versions (was:X and NeWS history) Christian Groessler 0 siblings, 1 reply; 204+ messages in thread From: Jon Steinhart @ 2017-09-13 0:14 UTC (permalink / raw) Adam Sampson writes: > Jon Steinhart <jon at fourwinds.com> writes: > > > I think that I'm the only person to write an X server outside of the X > > Consortium. > > When I was doing my PhD a few years ago, one of the case studies I used > was an X11 server that was written in occam 2 by Colin Willcock at the > University of Kent at Canterbury. I managed to recover Colin's source > code for the X server (in Transputer Development System format), which > is dated November 1988, from a very dusty machine backup... > > I also found the sources for Colin's 1991 report to the funding body on > the completion of the project, and his 1992 PhD thesis which describes > the same work. I rebuilt these in 2010 using a modern version of TeX, so > the appearance is probably different from what Colin intended (and the > cover-page dates are definitely wrong), but they're quite readable: > > https://stuff.offog.org/cw3-report-rebuilt.pdf > https://stuff.offog.org/cw3-thesis-rebuilt.pdf > > Note in particular the motivation stated in the report: "The worst of > these problems was the MEiKO C compiler, which (by mid-1988) proved > incapable of making any significant headway when presented with the > public-domain X-sources. [...] After consultation with the project > monitoring officers at RAL, we took the decision to investigate the > prospects for a complete re-implementation of the X-server in occam 2, > making no use of the public domain C sources." > > There have of course been other X server implementations more recently, > but they're less historically interesting! Cool, thanks for the info. Based on the date, this was probably X10, not X11. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions (was:X and NeWS history) 2017-09-13 0:14 ` Jon Steinhart @ 2017-09-13 16:38 ` Christian Groessler 2017-09-13 19:10 ` Kurt H Maier 2017-09-19 0:44 ` Random832 0 siblings, 2 replies; 204+ messages in thread From: Christian Groessler @ 2017-09-13 16:38 UTC (permalink / raw) On 09/13/17 02:14, Jon Steinhart wrote: > Cool, thanks for the info. Based on the date, this was probably X10, not > X11. Ever since I got in contact with X11 (around 92/93 with my first Linux and 386BSD installations), I was wondering what happened to the previous versions. You mention X10. Is there any documentation of source code of it available? And what about X1 to X9? regards, chris ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions (was:X and NeWS history) 2017-09-13 16:38 ` [TUHS] old X versions (was:X and NeWS history) Christian Groessler @ 2017-09-13 19:10 ` Kurt H Maier 2017-09-13 19:13 ` Henry Bent 2017-09-19 0:44 ` Random832 1 sibling, 1 reply; 204+ messages in thread From: Kurt H Maier @ 2017-09-13 19:10 UTC (permalink / raw) On Wed, Sep 13, 2017 at 06:38:29PM +0200, Christian Groessler wrote: > > You mention X10. Is there any documentation of source code of it available? You can look at some X10 source here: http://www.retro11.de/ouxr/43bsd/usr/src/new/X/ ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions (was:X and NeWS history) 2017-09-13 19:10 ` Kurt H Maier @ 2017-09-13 19:13 ` Henry Bent 0 siblings, 0 replies; 204+ messages in thread From: Henry Bent @ 2017-09-13 19:13 UTC (permalink / raw) On 13 September 2017 at 15:10, Kurt H Maier <khm at sciops.net> wrote: > On Wed, Sep 13, 2017 at 06:38:29PM +0200, Christian Groessler wrote: > > > > You mention X10. Is there any documentation of source code of it > available? > > You can look at some X10 source here: > http://www.retro11.de/ouxr/43bsd/usr/src/new/X/ > > Full X10R3 and R4 source is still on x.org: ftp://ftp.x.org/pub/X10R3/ ftp://ftp.x.org/pub/X10R4/ -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/3c7b3752/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions (was:X and NeWS history) 2017-09-13 16:38 ` [TUHS] old X versions (was:X and NeWS history) Christian Groessler 2017-09-13 19:10 ` Kurt H Maier @ 2017-09-19 0:44 ` Random832 2017-09-19 10:30 ` Nigel Williams 1 sibling, 1 reply; 204+ messages in thread From: Random832 @ 2017-09-19 0:44 UTC (permalink / raw) On Wed, Sep 13, 2017, at 12:38, Christian Groessler wrote: > Ever since I got in contact with X11 (around 92/93 with my first Linux > and 386BSD installations), I was > wondering what happened to the previous versions. > > You mention X10. Is there any documentation of source code of it > available? X10R3 and R4 are available from xorg at https://www.x.org/releases/ ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions (was:X and NeWS history) 2017-09-19 0:44 ` Random832 @ 2017-09-19 10:30 ` Nigel Williams 2017-09-19 14:05 ` Jon Steinhart 0 siblings, 1 reply; 204+ messages in thread From: Nigel Williams @ 2017-09-19 10:30 UTC (permalink / raw) Is the forerunner of X, I think called W? still around somewhere in source-form? ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions (was:X and NeWS history) 2017-09-19 10:30 ` Nigel Williams @ 2017-09-19 14:05 ` Jon Steinhart 2017-09-19 15:16 ` Gregg Levine 0 siblings, 1 reply; 204+ messages in thread From: Jon Steinhart @ 2017-09-19 14:05 UTC (permalink / raw) Nigel Williams writes: > Is the forerunner of X, I think called W? still around somewhere in source-form? No clue. Did a quick search and didn't find it. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions (was:X and NeWS history) 2017-09-19 14:05 ` Jon Steinhart @ 2017-09-19 15:16 ` Gregg Levine 2017-09-19 15:39 ` [TUHS] old X versions Chet Ramey ` (3 more replies) 0 siblings, 4 replies; 204+ messages in thread From: Gregg Levine @ 2017-09-19 15:16 UTC (permalink / raw) Hello! Wasn't the original project called "Athena", and wasn't it pursued by one of the many Labs at MIT? I remember going over it in a big way about the same time I started being an almost serious kernel hacker, and that was while the kernel created by Linus was using BitKeeper as its source control mechanism. This was around the turn of the century. Oddly enough I also pursued and engaged a company who attempted to combine an early X release with thier DOS based multitasking tool. The discussion was rewarding, but it did not save the company. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Tue, Sep 19, 2017 at 10:05 AM, Jon Steinhart <jon at fourwinds.com> wrote: > Nigel Williams writes: >> Is the forerunner of X, I think called W? still around somewhere in source-form? > > No clue. Did a quick search and didn't find it. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions 2017-09-19 15:16 ` Gregg Levine @ 2017-09-19 15:39 ` Chet Ramey 2017-09-19 18:23 ` Nemo 2017-09-19 15:40 ` [TUHS] old X versions (was:X and NeWS history) Clem Cole ` (2 subsequent siblings) 3 siblings, 1 reply; 204+ messages in thread From: Chet Ramey @ 2017-09-19 15:39 UTC (permalink / raw) On 9/19/17 11:16 AM, Gregg Levine wrote: > Hello! > Wasn't the original project called "Athena", and wasn't it pursued by > one of the many Labs at MIT? The athena project was indeed at MIT, and X was a part of that. This would have been started and developed during the mid-1980s (1983, to be exact). X's predecessor was a window system named W, which was developed at Stanford. Bob Scheifler used W as the basis for X. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://cnswww.cns.cwru.edu/~chet/ ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions 2017-09-19 15:39 ` [TUHS] old X versions Chet Ramey @ 2017-09-19 18:23 ` Nemo 2017-09-19 18:32 ` Clem Cole 2017-09-19 18:32 ` Chet Ramey 0 siblings, 2 replies; 204+ messages in thread From: Nemo @ 2017-09-19 18:23 UTC (permalink / raw) On 19 September 2017 at 11:39, Chet Ramey <chet.ramey at case.edu> wrote: > On 9/19/17 11:16 AM, Gregg Levine wrote: >> Hello! >> Wasn't the original project called "Athena", and wasn't it pursued by >> one of the many Labs at MIT? > > The athena project was indeed at MIT, and X was a part of that. This > would have been started and developed during the mid-1980s (1983, to be > exact). X's predecessor was a window system named W, which was developed > at Stanford. Bob Scheifler used W as the basis for X. I vaguely recall (assuming no bit rot) that IBM was also involved and they refused to release their portion under FRAND terms, leading Bob to write X. Anecodotes on W/X may be found in the delightful little book written by Borenstein titled "Programming as if people mattered". N. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet at case.edu http://cnswww.cns.cwru.edu/~chet/ ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions 2017-09-19 18:23 ` Nemo @ 2017-09-19 18:32 ` Clem Cole 2017-09-19 18:32 ` Chet Ramey 1 sibling, 0 replies; 204+ messages in thread From: Clem Cole @ 2017-09-19 18:32 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 738 bytes --] On Tue, Sep 19, 2017 at 2:23 PM, Nemo <cym224 at gmail.com> wrote: > > I vaguely recall (assuming no bit rot) that IBM was also involved and > they refused to release their portion under FRAND terms, leading Bob > to write X. Right, I remember that was mixed up in it. CMU (Andy "My hand is in your pocket" Carnegie) was willing to abide by the IBM terms and MIT (Paul "You gotta be kidding me" Gray) was not. So IBM got the IP from Andrew, while Athena was FOSS. IBM would eventually Open Source most of it. But originally, it was all private to them. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170919/3788c1f5/attachment-0001.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions 2017-09-19 18:23 ` Nemo 2017-09-19 18:32 ` Clem Cole @ 2017-09-19 18:32 ` Chet Ramey 2017-09-19 18:34 ` Jon Steinhart 2017-09-19 18:43 ` Chet Ramey 1 sibling, 2 replies; 204+ messages in thread From: Chet Ramey @ 2017-09-19 18:32 UTC (permalink / raw) On 9/19/17 2:23 PM, Nemo wrote: > On 19 September 2017 at 11:39, Chet Ramey <chet.ramey at case.edu> wrote: >> On 9/19/17 11:16 AM, Gregg Levine wrote: >>> Hello! >>> Wasn't the original project called "Athena", and wasn't it pursued by >>> one of the many Labs at MIT? >> >> The athena project was indeed at MIT, and X was a part of that. This >> would have been started and developed during the mid-1980s (1983, to be >> exact). X's predecessor was a window system named W, which was developed >> at Stanford. Bob Scheifler used W as the basis for X. > > I vaguely recall (assuming no bit rot) that IBM was also involved and > they refused to release their portion under FRAND terms, leading Bob > to write X. As I understand it, Scheifler began with W, which Paul Asente and Chris Kent had ported to Unix and given him a copy. He initially replaced its synchronous protocol with an asynchronous one and went on from there. I don't know whether IBM was involved with the V OS research, which was where W came from, or resisted its public release, but Scheifler certainly got a copy. Jon Steinhart covered a little bit of this in a message to this list last week. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://cnswww.cns.cwru.edu/~chet/ ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions 2017-09-19 18:32 ` Chet Ramey @ 2017-09-19 18:34 ` Jon Steinhart 2017-09-19 18:43 ` Chet Ramey 1 sibling, 0 replies; 204+ messages in thread From: Jon Steinhart @ 2017-09-19 18:34 UTC (permalink / raw) Chet Ramey writes: > On 9/19/17 2:23 PM, Nemo wrote: > > On 19 September 2017 at 11:39, Chet Ramey <chet.ramey at case.edu> wrote: > >> On 9/19/17 11:16 AM, Gregg Levine wrote: > >>> Hello! > >>> Wasn't the original project called "Athena", and wasn't it pursued by > >>> one of the many Labs at MIT? > >> > >> The athena project was indeed at MIT, and X was a part of that. This > >> would have been started and developed during the mid-1980s (1983, to be > >> exact). X's predecessor was a window system named W, which was developed > >> at Stanford. Bob Scheifler used W as the basis for X. > > > > I vaguely recall (assuming no bit rot) that IBM was also involved and > > they refused to release their portion under FRAND terms, leading Bob > > to write X. > > As I understand it, Scheifler began with W, which Paul Asente and Chris > Kent had ported to Unix and given him a copy. He initially replaced its > synchronous protocol with an asynchronous one and went on from there. > I don't know whether IBM was involved with the V OS research, which was > where W came from, or resisted its public release, but Scheifler > certainly got a copy. > > Jon Steinhart covered a little bit of this in a message to this list > last week. For what it's worth, I just looked in some old notebooks. I have a number of the V papers, and also some papers on VGTS which preceeded W. I'm sure that I have some of the W docs around somewhere but that'll take some more hunting. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions 2017-09-19 18:32 ` Chet Ramey 2017-09-19 18:34 ` Jon Steinhart @ 2017-09-19 18:43 ` Chet Ramey 2017-09-19 19:19 ` Stephen Kitt 1 sibling, 1 reply; 204+ messages in thread From: Chet Ramey @ 2017-09-19 18:43 UTC (permalink / raw) On 9/19/17 2:32 PM, Chet Ramey wrote: > On 9/19/17 2:23 PM, Nemo wrote: >> On 19 September 2017 at 11:39, Chet Ramey <chet.ramey at case.edu> wrote: >>> On 9/19/17 11:16 AM, Gregg Levine wrote: >>>> Hello! >>>> Wasn't the original project called "Athena", and wasn't it pursued by >>>> one of the many Labs at MIT? >>> >>> The athena project was indeed at MIT, and X was a part of that. This >>> would have been started and developed during the mid-1980s (1983, to be >>> exact). X's predecessor was a window system named W, which was developed >>> at Stanford. Bob Scheifler used W as the basis for X. >> >> I vaguely recall (assuming no bit rot) that IBM was also involved and >> they refused to release their portion under FRAND terms, leading Bob >> to write X. > > As I understand it, Scheifler began with W, which Paul Asente and Chris > Kent had ported to Unix and given him a copy. He initially replaced its > synchronous protocol with an asynchronous one and went on from there. This is covered in one of the original Athena papers: The X Window System by Scheifler and Gettys. I have the full set of "Project Athena: The First Ten Years"; it's in volume 1. I think that paper was presented at a couple of conferences, so there are probably copies floating around on the net somewhere. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://cnswww.cns.cwru.edu/~chet/ ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions 2017-09-19 18:43 ` Chet Ramey @ 2017-09-19 19:19 ` Stephen Kitt 0 siblings, 0 replies; 204+ messages in thread From: Stephen Kitt @ 2017-09-19 19:19 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 819 bytes --] On Tue, 19 Sep 2017 14:43:59 -0400, Chet Ramey <chet.ramey at case.edu> wrote: > On 9/19/17 2:32 PM, Chet Ramey wrote: > > As I understand it, Scheifler began with W, which Paul Asente and Chris > > Kent had ported to Unix and given him a copy. He initially replaced its > > synchronous protocol with an asynchronous one and went on from there. > > This is covered in one of the original Athena papers: The X Window System > by Scheifler and Gettys. I have the full set of "Project Athena: The First > Ten Years"; it's in volume 1. I think that paper was presented at a > couple of conferences, so there are probably copies floating around on the > net somewhere. E.g. in the ACM’s Digital Library: http://dl.acm.org/citation.cfm?id=24053 (from ACM Transactions on Graphics Volume 5 Issue 2). Regards, Stephen ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions (was:X and NeWS history) 2017-09-19 15:16 ` Gregg Levine 2017-09-19 15:39 ` [TUHS] old X versions Chet Ramey @ 2017-09-19 15:40 ` Clem Cole 2017-09-19 17:01 ` Steve Nickolas 2017-09-19 23:40 ` Wesley Parish 3 siblings, 0 replies; 204+ messages in thread From: Clem Cole @ 2017-09-19 15:40 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1313 bytes --] On Tue, Sep 19, 2017 at 11:16 AM, Gregg Levine <gregg.drwho8 at gmail.com> wrote: > > Wasn't the original project called "Athena", and wasn't it pursued by > one of the many Labs at MIT? Greg - not quite right, although I can see how I might look that way from the outside. The Athena project was MIT's reaction to the CMU Andrew Project. I'll not bring the somewhat humorous history but basic question asked was simple... assume CMU succeeded in building the proposed 3M 'SPICE' system for Andrew. MIT wanted to know: How would you deploy it? Athena set out to figure that out... It's interesting the two pieces of Athena that actually still live are X and Kerberos where were developed as part of the Athena project. I understand why Kerberos and much of that tech was needed if you were going to deploy hundreds of computers. I don't remember the argument for writing X - i.e. why it was needed, you'd have to ask Dan Geer (I've forgotten). FYI: In the case of Andrew, Mach and some of the AFS technology (and I've heard some suggest it helped to move IBM into the doing RIOS which eventually lead to Power/PC). Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170919/1a52929e/attachment-0001.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions (was:X and NeWS history) 2017-09-19 15:16 ` Gregg Levine 2017-09-19 15:39 ` [TUHS] old X versions Chet Ramey 2017-09-19 15:40 ` [TUHS] old X versions (was:X and NeWS history) Clem Cole @ 2017-09-19 17:01 ` Steve Nickolas 2017-09-19 17:15 ` Gregg Levine 2017-09-19 18:30 ` Nemo 2017-09-19 23:40 ` Wesley Parish 3 siblings, 2 replies; 204+ messages in thread From: Steve Nickolas @ 2017-09-19 17:01 UTC (permalink / raw) On Tue, 19 Sep 2017, Gregg Levine wrote: > Oddly enough I also pursued and engaged a company who attempted to > combine an early X release with thier DOS based multitasking tool. The > discussion was rewarding, but it did not save the company. Sounds like DesQview/X? -uso. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions (was:X and NeWS history) 2017-09-19 17:01 ` Steve Nickolas @ 2017-09-19 17:15 ` Gregg Levine 2017-09-19 18:56 ` Derek Fawcus 2017-09-19 18:30 ` Nemo 1 sibling, 1 reply; 204+ messages in thread From: Gregg Levine @ 2017-09-19 17:15 UTC (permalink / raw) Hello! Spot on. I've used it, and attempted to get it to work. Annoying thing it is, is that it only sees Novell's IPX based networking. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Tue, Sep 19, 2017 at 1:01 PM, Steve Nickolas <usotsuki at buric.co> wrote: > On Tue, 19 Sep 2017, Gregg Levine wrote: > >> Oddly enough I also pursued and engaged a company who attempted to >> combine an early X release with thier DOS based multitasking tool. The >> discussion was rewarding, but it did not save the company. > > > Sounds like DesQview/X? > > -uso. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions (was:X and NeWS history) 2017-09-19 17:15 ` Gregg Levine @ 2017-09-19 18:56 ` Derek Fawcus 2017-09-19 19:22 ` [TUHS] old X versions Arthur Krewat 2017-09-19 20:15 ` [TUHS] old X versions (was:X and NeWS history) Gregg Levine 0 siblings, 2 replies; 204+ messages in thread From: Derek Fawcus @ 2017-09-19 18:56 UTC (permalink / raw) On Tue, Sep 19, 2017 at 01:15:25PM -0400, Gregg Levine wrote: > Hello! > Spot on. I've used it, and attempted to get it to work. Annoying thing > it is, is that it only sees Novell's IPX based networking. That sounds... useless. I've got some vague memory of it being used on TCP/IP; and I wasn't even aware X ran over IPX (SPX?). Are you sure it isn't just ODI vs NDIS vs packet driver level stuff? DF ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions 2017-09-19 18:56 ` Derek Fawcus @ 2017-09-19 19:22 ` Arthur Krewat 2017-09-19 20:15 ` [TUHS] old X versions (was:X and NeWS history) Gregg Levine 1 sibling, 0 replies; 204+ messages in thread From: Arthur Krewat @ 2017-09-19 19:22 UTC (permalink / raw) On 9/19/2017 2:56 PM, Derek Fawcus wrote: > On Tue, Sep 19, 2017 at 01:15:25PM -0400, Gregg Levine wrote: >> Hello! >> Spot on. I've used it, and attempted to get it to work. Annoying thing >> it is, is that it only sees Novell's IPX based networking. > That sounds... useless. > > I've got some vague memory of it being used on TCP/IP; and I wasn't even aware X ran over IPX (SPX?). > > Are you sure it isn't just ODI vs NDIS vs packet driver level stuff? > > DF > http://www.cs.cmu.edu/afs/cs.cmu.edu/project/phrensy/pub/www/dvx/faq.txt To communicate with Unix machines, you must have a TCP/IP protocol stack that DESQview/X can communicate with. The following products are compatible: FTP's PCTCP HP/Lanman TCP/IP Novell's Lan Workplace for DOS PathWay Access (from The Wollongong Group Inc.) BW-TCP and BW-NFS (from Beame & Whiteside Software Ltd.) PC-NFS (from Sun Microsystems) I remember playing around with it a long time ago - I think I used PC-NFS with it. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions (was:X and NeWS history) 2017-09-19 18:56 ` Derek Fawcus 2017-09-19 19:22 ` [TUHS] old X versions Arthur Krewat @ 2017-09-19 20:15 ` Gregg Levine 1 sibling, 0 replies; 204+ messages in thread From: Gregg Levine @ 2017-09-19 20:15 UTC (permalink / raw) Hello! Basically it was indeed looking for an ODI delivered stack for IPX, it would further accept TCP/IP stacks, but it was an involved process. Oddly enough its all freeware with one group claiming to have the entire collection available free for download. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Tue, Sep 19, 2017 at 2:56 PM, Derek Fawcus <dfawcus+lists-tuhs at employees.org> wrote: > On Tue, Sep 19, 2017 at 01:15:25PM -0400, Gregg Levine wrote: >> Hello! >> Spot on. I've used it, and attempted to get it to work. Annoying thing >> it is, is that it only sees Novell's IPX based networking. > > That sounds... useless. > > I've got some vague memory of it being used on TCP/IP; and I wasn't even aware X ran over IPX (SPX?). > > Are you sure it isn't just ODI vs NDIS vs packet driver level stuff? > > DF ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions (was:X and NeWS history) 2017-09-19 17:01 ` Steve Nickolas 2017-09-19 17:15 ` Gregg Levine @ 2017-09-19 18:30 ` Nemo 1 sibling, 0 replies; 204+ messages in thread From: Nemo @ 2017-09-19 18:30 UTC (permalink / raw) On 19 September 2017 at 13:01, Steve Nickolas <usotsuki at buric.co> wrote: > On Tue, 19 Sep 2017, Gregg Levine wrote: > >> Oddly enough I also pursued and engaged a company who attempted to >> combine an early X release with thier DOS based multitasking tool. The >> discussion was rewarding, but it did not save the company. > > Sounds like DesQview/X? I used it but it still sat on top of DOS. I downloaded their GCC-based development tools and tried to build something for X (from X.org). I invoked the makefile and then went to finish laying subflooring in my living room, only to hear the PC rebooting in the other room. It turned out that many of the header-file names were identical in the first 8 characters. This led to recursive inclusion until it blew. N. > > -uso. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions (was:X and NeWS history) 2017-09-19 15:16 ` Gregg Levine ` (2 preceding siblings ...) 2017-09-19 17:01 ` Steve Nickolas @ 2017-09-19 23:40 ` Wesley Parish 2017-09-19 23:46 ` [TUHS] old X versions Grant Taylor 3 siblings, 1 reply; 204+ messages in thread From: Wesley Parish @ 2017-09-19 23:40 UTC (permalink / raw) Quoting Gregg Levine <gregg.drwho8 at gmail.com>: > Hello! > Wasn't the original project called "Athena", and wasn't it pursued by > one of the many Labs at MIT? I remember going over it in a big way > about the same time I started being an almost serious kernel hacker, > and that was while the kernel created by Linus was using BitKeeper as > its source control mechanism. This was around the turn of the century. > > Oddly enough I also pursued and engaged a company who attempted to > combine an early X release with thier DOS based multitasking tool. The > discussion was rewarding, but it did not save the company. DeskView/X? I came across that in the early nineties and thought it sounded promising, but as I heard nothing more of it after a while I thought, they've gone under. Wesley Parish > ----- > Gregg C Levine gregg.drwho8 at gmail.com > "This signature fought the Time Wars, time and again." > > > On Tue, Sep 19, 2017 at 10:05 AM, Jon Steinhart <jon at fourwinds.com> > wrote: > > Nigel Williams writes: > >> Is the forerunner of X, I think called W? still around somewhere in > source-form? > > > > No clue. Did a quick search and didn't find it. > "I have supposed that he who buys a Method means to learn it." - Ferdinand Sor, Method for Guitar "A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions 2017-09-19 23:40 ` Wesley Parish @ 2017-09-19 23:46 ` Grant Taylor 2017-09-20 0:06 ` Arthur Krewat 0 siblings, 1 reply; 204+ messages in thread From: Grant Taylor @ 2017-09-19 23:46 UTC (permalink / raw) On 09/19/2017 05:40 PM, Wesley Parish wrote: > DeskView/X? I came across that in the early nineties and thought as > I heard it sounded promising, but nothing more of it after a while > I thought, they've gone under. I ran across DeskView in the mid '90s too. I occasionally thought about how it did graphics in MS-DOS but never really thought that much about it. Since learning about DeskView's X11 (or 10?) server in the last few months, I'd like to get my hands on a copy to play with. You know, for giggles. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3717 bytes Desc: S/MIME Cryptographic Signature URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170919/f85a5224/attachment-0001.bin> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] old X versions 2017-09-19 23:46 ` [TUHS] old X versions Grant Taylor @ 2017-09-20 0:06 ` Arthur Krewat 0 siblings, 0 replies; 204+ messages in thread From: Arthur Krewat @ 2017-09-20 0:06 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 664 bytes --] http://www.chsoft.com/dv.html Or google it - it's all over the place. On 9/19/2017 7:46 PM, Grant Taylor wrote: > On 09/19/2017 05:40 PM, Wesley Parish wrote: >> DeskView/X? I came across that in the early nineties and thought as I >> heard it sounded promising, but nothing more of it after a while >> I thought, they've gone under. > > I ran across DeskView in the mid '90s too. I occasionally thought > about how it did graphics in MS-DOS but never really thought that much > about it. > > Since learning about DeskView's X11 (or 10?) server in the last few > months, I'd like to get my hands on a copy to play with. You know, > for giggles. > > > ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-12 22:11 ` [TUHS] X and NeWS history (long) Jon Steinhart 2017-09-12 22:58 ` Larry McVoy 2017-09-12 23:41 ` Adam Sampson @ 2017-09-13 0:29 ` Bakul Shah 2017-09-13 0:52 ` ron minnich 2017-09-13 0:56 ` Jon Steinhart 2017-09-13 15:09 ` Tony Finch 3 siblings, 2 replies; 204+ messages in thread From: Bakul Shah @ 2017-09-13 0:29 UTC (permalink / raw) > On Sep 12, 2017, at 3:11 PM, Jon Steinhart <jon at fourwinds.com> wrote: > > > As > a result, the X API is wide and shallow like the Mac, and full of interesting > race conditions to boot. The whole thing could have been done with less than > a dozen API calls. Unix still needs a decent graphics API (ideally one that can work over a network). Any thoughts on that? ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-13 0:29 ` [TUHS] X and NeWS history (long) Bakul Shah @ 2017-09-13 0:52 ` ron minnich 2017-09-13 0:54 ` Warner Losh ` (2 more replies) 2017-09-13 0:56 ` Jon Steinhart 1 sibling, 3 replies; 204+ messages in thread From: ron minnich @ 2017-09-13 0:52 UTC (permalink / raw) On Tue, Sep 12, 2017 at 5:30 PM Bakul Shah <bakul at bitblocks.com> wrote: > Unix still needs a decent graphics API (ideally one that can work over a > network). > > does anyone know or care about network graphics any more? From what I can tell, no. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/17a08332/attachment-0001.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-13 0:52 ` ron minnich @ 2017-09-13 0:54 ` Warner Losh 2017-09-13 0:56 ` ron minnich 2017-09-13 1:42 ` [TUHS] X and NeWS history (long) Arthur Krewat 2017-09-13 16:14 ` Lawrence Stewart 2 siblings, 1 reply; 204+ messages in thread From: Warner Losh @ 2017-09-13 0:54 UTC (permalink / raw) On Tue, Sep 12, 2017 at 6:52 PM, ron minnich <rminnich at gmail.com> wrote: > > > On Tue, Sep 12, 2017 at 5:30 PM Bakul Shah <bakul at bitblocks.com> wrote: > >> Unix still needs a decent graphics API (ideally one that can work over a >> network). >> >> > does anyone know or care about network graphics any more? From what I can > tell, no. > I still use them all the time... But maybe I'm a nobody... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/b3e4f3dd/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-13 0:54 ` Warner Losh @ 2017-09-13 0:56 ` ron minnich 2017-09-13 0:57 ` Warner Losh 2017-09-13 2:06 ` Kurt H Maier 0 siblings, 2 replies; 204+ messages in thread From: ron minnich @ 2017-09-13 0:56 UTC (permalink / raw) On Tue, Sep 12, 2017 at 5:54 PM Warner Losh <imp at bsdimp.com> wrote: > > > I still use them all the time... But maybe I'm a nobody... > > I know I am :-) It's strange nowadays to try to explain network graphics to interns. I feel like I'm giving them a tour of Jurassic Park. They like the idea once they get it, but they have no particular use for it from what I can see. Why does a phone need it? That's the determinant. ron > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/c3212f7b/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-13 0:56 ` ron minnich @ 2017-09-13 0:57 ` Warner Losh 2017-09-13 2:06 ` Kurt H Maier 1 sibling, 0 replies; 204+ messages in thread From: Warner Losh @ 2017-09-13 0:57 UTC (permalink / raw) On Tue, Sep 12, 2017 at 6:56 PM, ron minnich <rminnich at gmail.com> wrote: > > > On Tue, Sep 12, 2017 at 5:54 PM Warner Losh <imp at bsdimp.com> wrote: > >> >> >> I still use them all the time... But maybe I'm a nobody... >> >> > I know I am :-) > > It's strange nowadays to try to explain network graphics to interns. I > feel like I'm giving them a tour of Jurassic Park. They like the idea once > they get it, but they have no particular use for it from what I can see. > Why does a phone need it? That's the determinant. > VNC to the phone is the best thing ever... But I like a real keyboard... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/c53d3688/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-13 0:56 ` ron minnich 2017-09-13 0:57 ` Warner Losh @ 2017-09-13 2:06 ` Kurt H Maier 2017-09-13 3:34 ` ron minnich 1 sibling, 1 reply; 204+ messages in thread From: Kurt H Maier @ 2017-09-13 2:06 UTC (permalink / raw) On Wed, Sep 13, 2017 at 12:56:26AM +0000, ron minnich wrote: > Why does a phone need it? That's the determinant. Apple and Google spend a hell of a lot of time syncing everyone's data between phones, tablets, computers, surveillance platforms, and the like. Microsoft is making a lot of noise about jamming your phone into your computer to do things in a consistent manner. They call it 'convergence.' In 2009 I could just ssh into my phone and launch its messaging program from my desktop. It worked the other way, too -- I could log into my workstation from my phone. We lost that when iOS and Android destroyed all the competition. khm ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-13 2:06 ` Kurt H Maier @ 2017-09-13 3:34 ` ron minnich 2017-09-13 3:55 ` Jon Steinhart 0 siblings, 1 reply; 204+ messages in thread From: ron minnich @ 2017-09-13 3:34 UTC (permalink / raw) On Tue, Sep 12, 2017 at 7:06 PM Kurt H Maier <khm at sciops.net> wrote: > > > In 2009 I could just ssh into my phone and launch its messaging program > from my desktop. It worked the other way, too -- I could log into my > workstation from my phone. We lost that when iOS and Android destroyed > all the competition. > I don't disagree. I just think the knowledge of all that is lost, the same way so much knowledge of unix is lost. That's why we have things like systemd. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/50674af6/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-13 3:34 ` ron minnich @ 2017-09-13 3:55 ` Jon Steinhart 2017-09-13 15:16 ` Arthur Krewat 0 siblings, 1 reply; 204+ messages in thread From: Jon Steinhart @ 2017-09-13 3:55 UTC (permalink / raw) ron minnich writes: > > I don't disagree. I just think the knowledge of all that is lost, the same > way so much knowledge of unix is lost. That's why we have things like > systemd. It's amusing to me how many of the topics on this list I've included in my book in process because I feel that they're important. I look at the systemd problem slightly differently. In short, I was coming into work one night at BTL when Ken was heading out the door for his sabbatical at UCB with a stack of mag tapes under his arm. I see that as a pivotal moment in computer history. Students could learn from an actual real computer system; they had source code access. And, they had the ability to modify and contribute to that code. A lot of students from that era went out to do great things. Years later, the lower cost of PCs resulted in students using them for their work. Not only was MS-DOS not as advanced a system as UNIX, but source code access was gone. Students had to learn from contrived projects, and didn't have the ability to play with the guts of the operating system that they were using. While there are exceptions, I don't feel like students from the PC era are nearly as good. While Linux has sort of brought us back to the golden age of source access many of the people working on it are from the PC era and are trying to wedge their Microsoft-nonsensibilities into Linux. That's where things like systemd come from. Jon ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-13 3:55 ` Jon Steinhart @ 2017-09-13 15:16 ` Arthur Krewat 2017-09-13 15:42 ` [TUHS] X and NeWS history (long) [ really systemd, student access to real code ] Jon Steinhart 0 siblings, 1 reply; 204+ messages in thread From: Arthur Krewat @ 2017-09-13 15:16 UTC (permalink / raw) On 9/12/2017 11:55 PM, Jon Steinhart wrote: > > I look at the systemd problem slightly differently. In short, I was > coming into work one night at BTL when Ken was heading out the door for > his sabbatical at UCB with a stack of mag tapes under his arm. I see > that as a pivotal moment in computer history. Students could learn from > an actual real computer system; they had source code access. And, they > had the ability to modify and contribute to that code. A lot of students > from that era went out to do great things. Years later, the lower cost > of PCs resulted in students using them for their work. Not only was MS-DOS > not as advanced a system as UNIX, but source code access was gone. Students > had to learn from contrived projects, and didn't have the ability to play > with the guts of the operating system that they were using. Completely agree. To keep beating the dead horse, in high school we had access to a PDP-10, a KA10 running TOPS-10 5.06 - later they switched to 4 KS10s running TOPS-10 6.03 I gained some notoriety as a hacker, and was tasked by the consulting firm that ran the things to build a "better" MIC (a batch scripting tool that allowed you to run things offline and go back later to look at the results). I had exploited the original DEC version to give me access to [1,2] ;) Anyway, during that period, I was allowed to visit the installation, and if it was a weekend when students weren't on, to mount the "black" RP06 pack that had all the TOPS-10 sources on it, and look at or print out anything I wanted (look or print, same thing, really, the access was via LA120). I learned a lot. Went on to work for the place for a few years. Somewhere during that time, I was exposed to the IBM-PC and PCDOS. Except for my own projects in assembler, the IBM DOS and Technical Reference Manuals were all I had access to. HOWEVER - IBM in their infinite wisdom actually provided the sources to the BIOS in the manual. Still have that manual. That was awesome. I didn't have the DOS sources, but it wasn't hard to disassemble them with DEBUG and take a peak anyway. Back then, it was all written in assembler anyway, so it was only missing the symbols. Nothing was "out of reach". Now, with C or C++, or worse, higher-level languages being the default choices, that optimize everything to death, it's hard to disassemble anything and really "see" what it's trying to accomplish, and how. Not impossible, I've done some reverse engineering of various OS's, but nothing spectacular. For today's kids, well, it's a much different story. My son has a CS degree, but has almost no experience really peaking under the hood of any OS - some small ventures into kernels, but nothing huge like UNIX. Which brings me to another thing. Linux sources are freely available, and yet I don't see anyone really looking at them as an educational thing. I might be wrong, my experience in higher education is NONE. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) [ really systemd, student access to real code ] 2017-09-13 15:16 ` Arthur Krewat @ 2017-09-13 15:42 ` Jon Steinhart 0 siblings, 0 replies; 204+ messages in thread From: Jon Steinhart @ 2017-09-13 15:42 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 6000 bytes --] Arthur Krewat writes: > For today's kids, well, it's a much different story. My son has a CS > degree, but has almost no experience really peaking under the hood of > any OS - some small ventures into kernels, but nothing huge like UNIX. > Which brings me to another thing. Linux sources are freely available, > and yet I don't see anyone really looking at them as an educational > thing. I might be wrong, my experience in higher education is NONE. I know kids who have poked at this stuff in college. But, it opens a whole 'nother can of worms. UNIX was small. One could actually understand it pretty easily. Linux is huge. I hate to say it, but it's gotten bloated. And it suffers from a problem with open source. Don't get me wrong, I love open source, but it's not perfect. I'm worried that I'm going to come across as flogging my in-process book too much on this list. Not my intent, it's just that I've already written stuff that addresses this topic. Here's what I have to say on it (this part hasn't been attacked by my editor yet). It's way cool to me that I can run it through nroff and have it work! A Young Programmer’s Computer Primer Open Source Software Open source software is widely successful despite alarmist propaganda by some established closed‐source companies.1 A main advantage of open source software is that many more eyeballs are available to look at the code which translates into benefits such as greater security. Even if you used a closed source computer system there is a pretty good chance that you’re still using some open source components. The development of open source software was greatly enhanced by the Internet and ‘‘cloud’’ services. It’s trivial to find open source projects and to start your own. But, and this is a big but, the majority of open source projects out there are garbage. A lot of open source software comes from student projects. Since they’re often first projects, the authors haven’t yet mastered the art of writing good code. And, much of this software is unfinished as the student finished their class or graduated or just moved on. It’s often easier to rewrite something than it is to decipher someone else’s poorly written and documented code. This is a viscous cycle because the rewrite often doesn’t get done so there are multiple ver‐ sions which don’t work in different ways.2 It’s often difficult to determine whether or not there is a good working version of something because there is so much litter. There is a belief that one of the advantages of open source software is that you can fix bugs that you find. Unfortunately, much of this software is so poorly written and completely undocumented making the amount of effort required too great for a casual user. Just because something is open source doesn’t mean that it’s a great example of the craft. But, you can learn what not to do just as well as you can learn what to do from looking at other’s code. There are two indicators, one positive and one negative, that you can use to help determine the quality of a piece of code. The positive indicator is whether or not a project is under active development3 with more than one contributor. It often helps if a project is supported by some organization. Many of the major open source projects originated at companies4 who still support their development. Others have been donated by companies to foundations that support their development. This often yields a consistent vision which keeps the project on track. This indicator is not completely reliable5 so take it with a grain of salt. The negative indicator is the type and quantity of dialog that you’ll see at various programmer ‘‘self‐help’’ web sites. If you see lots of ‘‘I can’t figure out how to make this work?’’ and ‘‘Where do I start to make this change?’’ questions then it’s probably not a great piece of code. Furthermore, if the responses are mostly useless non‐answers or snarky and unhelpful then the project probably lacks good develop‐ ers. Developers who blame the questioner for their own lack of qual‐ ity work are not good role models. Of course, it’s also a bad sign if there are no comments or questions as it means that the code is proba‐ bly not used. Cautionary tales aside, open source is a great thing. Make your code open source when it makes sense to do so. But first, learn how to do a good job so that your code becomes a good example to others. __________________________ 1 For example, Microsoft claimed that ‘‘Open source is an intel‐ lectual property destroyer. I can’t imagine something that could be worse than this for the software business and the in‐ tellectual‐property business’’ despite the fact that they were secretly using open source tools in‐house. 2 I recently needed to extract tags from mp3 files and tried six different open‐source programs each of which failed in a differ‐ ent way. 3 This doesn’t apply to projects that have been around for a long time and are actually ‘‘done’’. 4 One must be careful of open source projects created at companies who are later acquired by companies with different philosophies. For example, Sun Microsystems was a prodigious developer of open source software including OpenOffice, Java, and VirtualBox. However, Sun was acquired by Oracle who ended support for some of these projects and tried to find ways to control and monetize others; see the Oracle versus Google lawsuit for details. 5 For example, the code base for the firefox web browser is a poorly documented complete mess. Copyright © 2001‐2017 Jonathan E. Steinhart. All Rights Reserved - Page 2 ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-13 0:52 ` ron minnich 2017-09-13 0:54 ` Warner Losh @ 2017-09-13 1:42 ` Arthur Krewat 2017-09-13 2:27 ` Grant Taylor 2017-09-13 16:14 ` Lawrence Stewart 2 siblings, 1 reply; 204+ messages in thread From: Arthur Krewat @ 2017-09-13 1:42 UTC (permalink / raw) Try installing Oracle products on UNIX/Linux without X. Better yet, try doing it on a remote machine on the other side of the world. While KVMs like a Dell DRAC or Sun LOM, and virtualization consoles help a lot, it's nice to be able to "ssh -X" to a remote machine and run that installer back to my local VNC server. If I had a decent X windows implementation locally, I'd use that instead of VNC. X had it's issues. But it's still alive and well - maybe because of Java ;) On 9/12/2017 8:52 PM, ron minnich wrote: > > > On Tue, Sep 12, 2017 at 5:30 PM Bakul Shah <bakul at bitblocks.com > <mailto:bakul at bitblocks.com>> wrote: > > Unix still needs a decent graphics API (ideally one that can work > over a network). > > > does anyone know or care about network graphics any more? From what I > can tell, no. > > ron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/7f00c728/attachment-0001.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-13 1:42 ` [TUHS] X and NeWS history (long) Arthur Krewat @ 2017-09-13 2:27 ` Grant Taylor 0 siblings, 0 replies; 204+ messages in thread From: Grant Taylor @ 2017-09-13 2:27 UTC (permalink / raw) On 09/12/2017 07:42 PM, Arthur Krewat wrote: > Try installing Oracle products on UNIX/Linux without X. Better yet, try > doing it on a remote machine on the other side of the world. Ouch! Doing it half way across the US was bad enough. I'd hate to experience half way around the world. > While KVMs like a Dell DRAC or Sun LOM, and virtualization consoles help > a lot, it's nice to be able to "ssh -X" to a remote machine and run that > installer back to my local VNC server. (Don't forget the -Y to forward authentication. ;-) I completely agree. Also, I believe that graphic console has a completely different security exposure compared to allowing someone to use X remotely. (Via ssh forwarding or more traditionally across the network.) > If I had a decent X windows implementation locally, I'd use that instead > of VNC. I actually ended up going the other way. X11 is nice when it works. However, I found that I spent a LOT of time waiting on X11 to chat back and forth. Comparatively VNC is (IMHO) a lot better at lower bandwidth and / or higher latency. Also, running Xvnc (server) on the remote system allows you to (dis)connect the VNC client at will. Same advantages as screen / tmux, but for X11. > X had it's issues. But it's still alive and well - maybe because of Java ;) I personally look fondly on the days when you could set the DISPLAY variable and launch your GUI application. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3717 bytes Desc: S/MIME Cryptographic Signature URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/f0e379c5/attachment.bin> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-13 0:52 ` ron minnich 2017-09-13 0:54 ` Warner Losh 2017-09-13 1:42 ` [TUHS] X and NeWS history (long) Arthur Krewat @ 2017-09-13 16:14 ` Lawrence Stewart 2 siblings, 0 replies; 204+ messages in thread From: Lawrence Stewart @ 2017-09-13 16:14 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 688 bytes --] > On 2017, Sep 12, at 8:52 PM, ron minnich <rminnich at gmail.com> wrote: > > > > On Tue, Sep 12, 2017 at 5:30 PM Bakul Shah <bakul at bitblocks.com <mailto:bakul at bitblocks.com>> wrote: > Unix still needs a decent graphics API (ideally one that can work over a network). > > > does anyone know or care about network graphics any more? From what I can tell, no. > > ron Well I do. I’ve been looking at gigantic simulator trace files recently, and the graphics is far smaller than the underlying data. -L -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/263b125a/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-13 0:29 ` [TUHS] X and NeWS history (long) Bakul Shah 2017-09-13 0:52 ` ron minnich @ 2017-09-13 0:56 ` Jon Steinhart 2017-09-13 1:34 ` Bakul Shah 2017-09-13 2:43 ` Grant Taylor 1 sibling, 2 replies; 204+ messages in thread From: Jon Steinhart @ 2017-09-13 0:56 UTC (permalink / raw) Bakul Shah writes: > > Unix still needs a decent graphics API (ideally one that can work over a network). > Any thoughts on that? Wow, big topic. Rather than getting into it in detail at the moment I'm curious as to why you think that it's important for it to work over a network. Before you bite my head off for that question, I'm not suggesting that there's no value in taking data from somewhere on a network and using it on a local machine. Back in the darker ages of the Green Flash (Tektronix storage tubes like the 4014) it was common to display remote data on a local system. The data in those days arrived via RS-232. Depending on the application, one could shovel 4014 commands over the wire or just raw data and use a local program to generate drawing commands. I've never been convinced that the way that X did it made sense. Sure, you'd here people say things like "your remote Cray can draw stuff on your local screen." But it wasn't just that; using X your Cray also had to draw and manage your user interface: scroll bars, buttons, and so on unless you wanted to create a separate protocol so that you could run your user interface locally and have it communicate with the remote application. Of course, X was enough of a pig that maybe using a Cray to drive a scroll bar made sense :-) So before getting off into graphics APIs I think that it would be interesting to hash this out. BTW, one of the best things about NeWS was the fact that with a reasonable set of conventions the user interface personality could live in the server and be applied to all applications. Contrast that with X where each application links in a UI library, and if your screen looks anything like mine there isn't a lot of consistency because different applications use different libraries. One of the problems with NeWS was that this was so much fun to play with that the people doing the work kept on coming up with new ideas faster than they could implement the old ones so there was difficulty completing toolkit projects. Jon ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-13 0:56 ` Jon Steinhart @ 2017-09-13 1:34 ` Bakul Shah 2017-09-13 2:43 ` Grant Taylor 1 sibling, 0 replies; 204+ messages in thread From: Bakul Shah @ 2017-09-13 1:34 UTC (permalink / raw) > On Sep 12, 2017, at 5:56 PM, Jon Steinhart <jon at fourwinds.com> wrote: > > Bakul Shah writes: >> >> Unix still needs a decent graphics API (ideally one that can work over a network). >> Any thoughts on that? > > Wow, big topic. Rather than getting into it in detail at the moment I'm curious > as to why you think that it's important for it to work over a network. Heavy number crunching generating some data for display may be far from the one displaying the data. [sensor input | storage] => [computation} <=> [display/user input] > Before you bite my head off for that question, I'm not suggesting that there's > no value in taking data from somewhere on a network and using it on a local > machine. ... > So before getting off into graphics APIs I think that it would be interesting > to hash this out. Indeed. The question really is where in the pipeline from gobs of raw data to number crunching transformations to display does the network split lie. In a sense we already have a split (GPU vs CPU) but it is highly specialized. Camera, mouse, graphics tablet, keyboard, other sensor inputs will be (or should be) near the display but may be processed far away in an application specific manner. I suspect here too we may go through Sutherland's wheel of reincarnation. We can offload more GUI processing in the server but as GUI becomes more sophisticated (or complicated), it will feel slow. I can envision using a RaspberryPi as a "graphics processor" but we still need a protocol between the 'Pi and the "backend". If done right, I wouldn't want to touch the innards of the s/w running on the 'Pi when writing a game or something needing visualization. > BTW, one of the best things about NeWS was the fact that with a reasonable set > of conventions the user interface personality could live in the server and be > applied to all applications. Contrast that with X where each application links > in a UI library, and if your screen looks anything like mine there isn't a lot > of consistency because different applications use different libraries. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-13 0:56 ` Jon Steinhart 2017-09-13 1:34 ` Bakul Shah @ 2017-09-13 2:43 ` Grant Taylor 2017-09-13 3:01 ` Jon Steinhart 1 sibling, 1 reply; 204+ messages in thread From: Grant Taylor @ 2017-09-13 2:43 UTC (permalink / raw) On 09/12/2017 06:56 PM, Jon Steinhart wrote: > Wow, big topic. Rather than getting into it in detail at the moment I'm curious > as to why you think that it's important for it to work over a network. I personally really like the ability to SSH to a machine (*) using -XY and run Oracle's installer such that it's display shows up on my notebook. I find that SO MUCH EASIER than trying to get the iDRAC / RSA / IMM / etc to work. Usually they require multiple ports and protocols (often UDP, which is a pain through SSH). For me, X11 forwarding just works. - Thank you to everyone that spent so much time and energy getting it to work. > Before you bite my head off for that question, I'm not suggesting that there's > no value in taking data from somewhere on a network and using it on a local > machine. I think there's a distinct and large difference in data and display I/O. > Back in the darker ages of the Green Flash (Tektronix storage tubes like the > 4014) it was common to display remote data on a local system. The data in > those days arrived via RS-232. Depending on the application, one could shovel > 4014 commands over the wire or just raw data and use a local program to generate > drawing commands. I've often contemplated SIXEL graphics in an error prompt from remote systems. (This is a different topic, which itself relies on answer back.) > I've never been convinced that the way that X did it made sense. Sure, you'd > here people say things like "your remote Cray can draw stuff on your local > screen." But it wasn't just that; using X your Cray also had to draw and > manage your user interface: scroll bars, buttons, and so on unless you wanted > to create a separate protocol so that you could run your user interface > locally and have it communicate with the remote application. Of course, X was > enough of a pig that maybe using a Cray to drive a scroll bar made sense :-) Maybe I'm a n00b and don't know better, but I'd think that would be a use case for nested X running on a local (closer than the Cray) machine. So all the Cray needed to do was to send program I/O to the (nested) X server. Then the (nested) X server could handle scroll bars and other local window manager eye candy. I think the Cray would run something much like X does if you aren't running a window manager. Simple, single application, no frills. I think. > So before getting off into graphics APIs I think that it would be interesting > to hash this out. > > BTW, one of the best things about NeWS was the fact that with a reasonable set > of conventions the user interface personality could live in the server and be > applied to all applications. Contrast that with X where each application links > in a UI library, and if your screen looks anything like mine there isn't a lot > of consistency because different applications use different libraries. > > One of the problems with NeWS was that this was so much fun to play with that > the people doing the work kept on coming up with new ideas faster than they > could implement the old ones so there was difficulty completing toolkit > projects. LOL Feeping Creatureism? -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3717 bytes Desc: S/MIME Cryptographic Signature URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/2e26e6b3/attachment-0001.bin> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-13 2:43 ` Grant Taylor @ 2017-09-13 3:01 ` Jon Steinhart 2017-09-13 3:25 ` Grant Taylor 0 siblings, 1 reply; 204+ messages in thread From: Jon Steinhart @ 2017-09-13 3:01 UTC (permalink / raw) Grant Taylor writes: > I personally really like the ability to SSH to a machine (*) using -XY > and run Oracle's installer such that it's display shows up on my notebook. Well, I agree that this is one area in which X does OK. Although, being a command line sort of guy, I'm happy to ssh into a machine and run commands. I try to avoid non-scriptable GUIs. I don't administer headless machines, and stay very far away from Oracle. I'm not sure what their installer does, but usually running X requires an installed and running system. So since a number of people have justified networked graphics we're back to the question of what an API should look like. At a very high level, it needs to be modular because there is no one thing that gets done with graphics, and there's no reason to carry a huge API around just because you need a small part of it. In particular, there is a distinction between applications that spit out geometry and those that spit out mass quantities of pixel/voxel data. Also, because of the way that this discussion started, I'm not sure whether or not resource management (windows, keyboard, etc.) falls under the umbrella of graphics. Jon ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-13 3:01 ` Jon Steinhart @ 2017-09-13 3:25 ` Grant Taylor 2017-09-13 3:27 ` Jon Steinhart 0 siblings, 1 reply; 204+ messages in thread From: Grant Taylor @ 2017-09-13 3:25 UTC (permalink / raw) On 09/12/2017 09:01 PM, Jon Steinhart wrote: > Well, I agree that this is one area in which X does OK. I also like how X will allow me to have windows from remote programs mixed with local programs and does not require a full desktop. (A feature that RDP has gotten in the last 10 ? years.) > Although, being a command line sort of guy, I'm happy to ssh into a machine > and run commands. I try to avoid non-scriptable GUIs. I completely agree. > I don't administer headless machines, and stay very far away from Oracle. > I'm not sure what their installer does, but usually running X requires an > installed and running system. Sadly my use case what proving to a ... questionable DBA that things could work as directed, despite his objections the other way. Since I was not familiar with Oracle RAC and Oracle DB, I needed to go the front door route, taking screen shots and documenting each and everything I did. (Partially for political reasons.) Yes, you do need an installed (base) OS with some dependencies. Thankfully you don't need a full window manager or the bloat that comes with things like Gnome / KDE. > So since a number of people have justified networked graphics we're back > to the question of what an API should look like. At a very high level, > it needs to be modular because there is no one thing that gets done with > graphics, and there's no reason to carry a huge API around just because > you need a small part of it. In particular, there is a distinction > between applications that spit out geometry and those that spit out mass > quantities of pixel/voxel data. "voxel"? I'll have to look that up. > Also, because of the way that this discussion started, I'm not sure whether > or not resource management (windows, keyboard, etc.) falls under the > umbrella of graphics. I expect that they should be included in such discussions. After all, they are intimately related. GUI applications are of questionable value if you can't interact with them. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3717 bytes Desc: S/MIME Cryptographic Signature URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/01b07472/attachment.bin> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-13 3:25 ` Grant Taylor @ 2017-09-13 3:27 ` Jon Steinhart 0 siblings, 0 replies; 204+ messages in thread From: Jon Steinhart @ 2017-09-13 3:27 UTC (permalink / raw) Grant Taylor writes: > "voxel"? I'll have to look that up. I'll save you the trouble. 3D. Volume equivalent of a pixel. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-12 22:11 ` [TUHS] X and NeWS history (long) Jon Steinhart ` (2 preceding siblings ...) 2017-09-13 0:29 ` [TUHS] X and NeWS history (long) Bakul Shah @ 2017-09-13 15:09 ` Tony Finch 2017-09-13 15:19 ` Jon Steinhart 3 siblings, 1 reply; 204+ messages in thread From: Tony Finch @ 2017-09-13 15:09 UTC (permalink / raw) A couple of NeWS-related links which I saved back in March: A book / conference report surveying the state of Window Management in 1985, specifically the chapter on an early version of NeWS: http://www.chilton-computing.org.uk/inf/literature/books/wm/p005.htm The amazing NeFS, the Network Extensible File System, which was supposed to be version 3 of NFS, based on in-kernel PostScript. Thankfully it died :-) http://www.donhopkins.com/home/nfs3_0.pdf Last year, an appreciation of NeWS written from a modern perspective, including some comparisons with the JS / HTML / CSS / SVG web: https://medium.com/@slavapestov/yesterdays-news-c52f2be95205 Finally, a question: is there a good comparison of NeWS vs NeXT Display Postscript anywhere? Tony. -- f.anthony.n.finch <dot at dotat.at> http://dotat.at/ - I xn--zr8h punycode Dogger: North or northwest 6 to gale 8, increasing severe gale 9 or storm 10 at first. Moderate or rough, occasionally very rough at first. Rain or thundery showers. Good, occasionally poor. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] X and NeWS history (long) 2017-09-13 15:09 ` Tony Finch @ 2017-09-13 15:19 ` Jon Steinhart 0 siblings, 0 replies; 204+ messages in thread From: Jon Steinhart @ 2017-09-13 15:19 UTC (permalink / raw) Tony Finch writes: > Finally, a question: is there a good comparison of NeWS vs NeXT Display > Postscript anywhere? Not that I'm aware of. The main difference was in the name; Display Postscipt just displayed Postscript; it's what NeXT used for higher quality rendering. NeWS was a window management system that included Postscript graphics. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-12 17:04 ` Arthur Krewat 2017-09-12 17:07 ` Larry McVoy 2017-09-12 22:11 ` [TUHS] X and NeWS history (long) Jon Steinhart @ 2017-09-12 23:33 ` Dave Horsfall 2 siblings, 0 replies; 204+ messages in thread From: Dave Horsfall @ 2017-09-12 23:33 UTC (permalink / raw) On Tue, 12 Sep 2017, Arthur Krewat wrote: > Oh, do, please go on ;) > > On 9/12/2017 11:35 AM, Jon Steinhart wrote: >> As the guy who single-handedly prevented X from becoming an ANSI >> standard, I'd be happy to start another thread on this topic if people >> are interested. Seconded... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-12 15:35 ` [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] Jon Steinhart 2017-09-12 16:57 ` Larry McVoy 2017-09-12 17:04 ` Arthur Krewat @ 2017-09-12 20:15 ` Steve Johnson 2017-09-13 2:23 ` Larry McVoy 2017-09-13 7:30 ` arnold 2 siblings, 2 replies; 204+ messages in thread From: Steve Johnson @ 2017-09-12 20:15 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 4979 bytes --] Funny. From the outside I had a rather different view of why Sun was successful. In 1986 I came to CA to work for what became Ardent/Stardent. We made the decision to go with Sun disc-less workstations. They got us more computing power, on paper, for less $$. Roughly a quarter of the machines shipped to us were DOA. When we got them running, the OS had a memory leak and needed to be rebooted several times a day. The NFS server had the delightful property of sometimes inserting 1024 zeros into a file it was writing or serving. (It was so bad that we hacked the OS to check every executable for 0-blocks in the instruction space and refuse to run it. This was especially true for the MIPS cross compiler -- 0 was a NOP on the MIPS, and encountering a block of zeros caused execution to slide down a slippery slope of NOPs into the middle of some other routine with a different stack layout, where it proceeded to do the most mysterious things...) We would go out to lunch every day and trash talk Sun up one side and down the other. And then we would go back to work and order more Suns. Because THEY UNDERSTOOD WHAT WE NEEDED, and were TRYING TO GIVE IT TO US. The other manufacturers were selling application delivery vehicles rather than attempting to support software development. Eventually we ironed out many of the issues (often by changing or hacking the code). The only fly in the ointment was the service department. Dealing with Sun customer service was like spitting into the wind. We would report the same bug every week and they swore the bug had not been reported before. The memory leak problem became so serious that we told them that we would only renew the service agreement if they would put a date when that would be fixed. They refused to do so, and we canceled the service contract, bought a couple of extra Suns for spares, and heaved a sigh of relief. Steve ----- Original Message ----- From: "Jon Steinhart" <jon@fourwinds.com> To:<tuhs at tuhs.org> Cc: Sent:Tue, 12 Sep 2017 08:35:24 -0700 Subject:Re: [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] arnold at skeeve.com writes: > > In particular, the creation of NFS and then the efforts to make it into > a de-facto standard (giving away the RPC and XDR code) was a HUGE thing. > > They weren't afraid to swim upstream, either. Even though NeWS never took > off (even when combined with an X server), it was an interesting design, > ahead of its time even. It's interesting that you mention the two of these together. It's my opinion that the main reason that NeWS failed was because of the success of NFS. I recall that Apollo was really pissed off by NFS because they felt that their token-ring network was better but lost because NFS was given away. In hindsight, they were wrong; while the token-ring performed better in large networks, the advent of switches made that moot. In any case, when NeWS was released nobody except Sun knew how to do the graphics (even Adobe didn't know how to do it fast for display) and Apollo et. al. was worried that Sun would give NeWS away and make it yet another de facto standard a la NFS. This led to the formation of the Hamilton Group which was a thinly-disguised industry consortium that existed only for the purpose of making sure that NeWS didn't succeed. > DEC, IBM, and HP, all seemed to be playing follow the leader to Sun for > many years. I mentioned this to a lot of people after Sun died. Few seem to realize how much of what became PC manufacturing technology resulted from innovations at Sun. ron at ronnatalie.com writes: > > NeWS had serious issues. However, the same guy who was the NeWS proponent > learned from mistakes and the result was the must more successful Sun > tehnology: JAVA. I'm going to take issue with the above. NeWS had way fewer serious issues than X. It's main reason for failure was the coordinated effort to kill it from others in the industry. As the guy who single-handedly prevented X from becoming an ANSI standard, I'd be happy to start another thread on this topic if people are interested. Part of the result of the Hamilton Group effort was the misguided attempt to merge X and NeWS which was a botched disaster. Java is not the result of learning from mistakes in NeWS. I have joked with James that I feel that his legacy is being the person who first realizes that technology is changing to the point where something can be done using an interpreter. If you look at his project history, he's done this many times. I think that it's more accurate to say that Java is the result of a lifetime of learning from interpreter projects. I fully expect some new interpreter to take over AWS sometime soon :-) Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/5d44e60c/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-12 20:15 ` Steve Johnson @ 2017-09-13 2:23 ` Larry McVoy 2017-09-14 0:53 ` Nemo 2017-09-13 7:30 ` arnold 1 sibling, 1 reply; 204+ messages in thread From: Larry McVoy @ 2017-09-13 2:23 UTC (permalink / raw) On Tue, Sep 12, 2017 at 01:15:43PM -0700, Steve Johnson wrote: > We would go out to lunch every day and trash talk Sun up one side and > down the other.?? And then we would go back to work and order more > Suns.?? Because THEY UNDERSTOOD WHAT WE NEEDED, and were TRYING TO > GIVE IT TO US.?? I love this. I was one of those guys trying to give you what you wanted. I did POSIX conformance in SunOS and as part of that I wrote lint libraries for 4x BSD, SunOS, Sys V, etc. I made it so you could use a Sun machine as your dev environment but target other operating systems, lint could tell you if you were using a Sun thing that didn't work on $OS. I had a huge blowup with Gingell (a high ranking Sun engineer, he had some fancy title that made him like a VP) over this. The libraries added 40KB to the install image and he didn't like that. I told him if you don't ship this I quit. He shipped it. The details aside, that story supports your view that we wanted to help you. We were developers and we wanted to help developers. And it worked. Back at that time every open source (or closed source but sent around) project had makefiles that "just worked" on Sun machines. MIPS? Well that's IRIX, yeah, you need to do this or that. On a Sun? It just worked. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-13 2:23 ` Larry McVoy @ 2017-09-14 0:53 ` Nemo 2017-09-14 1:18 ` Henry Bent ` (3 more replies) 0 siblings, 4 replies; 204+ messages in thread From: Nemo @ 2017-09-14 0:53 UTC (permalink / raw) On 12/09/2017, Larry McVoy <lm at mcvoy.com> wrote (in part): > And it worked. Back at that time every open source (or closed source but > sent around) project had makefiles that "just worked" on Sun machines. > MIPS? Well that's IRIX, yeah, you need to do this or that. On a Sun? > It just worked. Oh, I nearly wept when I read this. Building a typical project nowadays is so painful -- the makefile works on one particular Linux distro and woe betide the rest. N. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 0:53 ` Nemo @ 2017-09-14 1:18 ` Henry Bent 2017-09-14 3:15 ` Larry McVoy ` (2 subsequent siblings) 3 siblings, 0 replies; 204+ messages in thread From: Henry Bent @ 2017-09-14 1:18 UTC (permalink / raw) On 13 September 2017 at 20:53, Nemo <cym224 at gmail.com> wrote: > On 12/09/2017, Larry McVoy <lm at mcvoy.com> wrote (in part): > > And it worked. Back at that time every open source (or closed source but > > sent around) project had makefiles that "just worked" on Sun machines. > > MIPS? Well that's IRIX, yeah, you need to do this or that. On a Sun? > > It just worked. > > Oh, I nearly wept when I read this. Building a typical project > nowadays is so painful -- the makefile works on one particular Linux > distro and woe betide the rest. > > N. > Henry Spencer's final commandment, as preserved at https://www.lysator.liu.se/c/ten-commandments.html , seems particularly apt here. Even now, in the days of configure scripts and their ilk, if your code blindly assumes that a "common" function will be present then it is destined to fail somewhere. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/6db1ff44/attachment-0001.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 0:53 ` Nemo 2017-09-14 1:18 ` Henry Bent @ 2017-09-14 3:15 ` Larry McVoy 2017-09-14 9:35 ` Rico Pajarola 2017-09-15 3:16 ` Dave Horsfall 3 siblings, 0 replies; 204+ messages in thread From: Larry McVoy @ 2017-09-14 3:15 UTC (permalink / raw) On Wed, Sep 13, 2017 at 08:53:07PM -0400, Nemo wrote: > On 12/09/2017, Larry McVoy <lm at mcvoy.com> wrote (in part): > > And it worked. Back at that time every open source (or closed source but > > sent around) project had makefiles that "just worked" on Sun machines. > > MIPS? Well that's IRIX, yeah, you need to do this or that. On a Sun? > > It just worked. > > Oh, I nearly wept when I read this. Building a typical project > nowadays is so painful -- the makefile works on one particular Linux > distro and woe betide the rest. I tend to just use Debian and Debian derived releases and stuff works for me. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 0:53 ` Nemo 2017-09-14 1:18 ` Henry Bent 2017-09-14 3:15 ` Larry McVoy @ 2017-09-14 9:35 ` Rico Pajarola 2017-09-14 11:11 ` arnold 2017-09-15 3:16 ` Dave Horsfall 3 siblings, 1 reply; 204+ messages in thread From: Rico Pajarola @ 2017-09-14 9:35 UTC (permalink / raw) On Thu, Sep 14, 2017 at 2:53 AM, Nemo <cym224 at gmail.com> wrote: > On 12/09/2017, Larry McVoy <lm at mcvoy.com> wrote (in part): > > And it worked. Back at that time every open source (or closed source but > > sent around) project had makefiles that "just worked" on Sun machines. > > MIPS? Well that's IRIX, yeah, you need to do this or that. On a Sun? > > It just worked. > > Oh, I nearly wept when I read this. Building a typical project > nowadays is so painful -- the makefile works on one particular Linux > distro and woe betide the rest. > I also wept a bit when reading this. I once built gnome from source (don't ask why), on Solaris, IRIX, and HP-UX. That was also the month I learned how to use "autoconf" and "libtool" as swearwords... But on modern Linux? That's not my experience. Maybe we just have different standards for "just works", but a typical "modern" open source project nowadays "just works" (for my definition of just works) on pretty much any modern system including FreeBSD (type: ./configure; make && make install). > N. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/69d2b950/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 9:35 ` Rico Pajarola @ 2017-09-14 11:11 ` arnold 2017-09-14 12:13 ` Rico Pajarola 2017-09-14 13:21 ` Steffen Nurpmeso 0 siblings, 2 replies; 204+ messages in thread From: arnold @ 2017-09-14 11:11 UTC (permalink / raw) Rico Pajarola <rp at servium.ch> wrote: > I also wept a bit when reading this. I once built gnome from source (don't > ask why), on Solaris, IRIX, and HP-UX. That was also the month I learned > how to use "autoconf" and "libtool" as swearwords... Libtool for sure. Autoconf is something you have to come to a negotiated truce with and then it's OK. :-) > But on modern Linux? That's not my experience. Maybe we just have different > standards for "just works", but a typical "modern" open source project > nowadays "just works" (for my definition of just works) on pretty much any > modern system including FreeBSD (type: ./configure; make && make install). Like anything else, it depends on the quality, knowledge, and experience of the developers. The problem isn't really the Autotools as much as inexperienced developers who don't understand that all the world is not Linux and who thus feel free to assume way too many things. We just went through the exercise of building the latest libpcap for Linux, Solaris, AIX and HP-UX. Nightmarish, due to dependency upon flex, which in turn took an act of Congress in order to get it to build, particularly on AIX, but also not so easy on the others. OTOH, the older GNU projects, with experienced developers (gawk, Bash) don't exhibit such issues. My two cents (as one of those battle-scarred developers :-) Arnold ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 11:11 ` arnold @ 2017-09-14 12:13 ` Rico Pajarola 2017-09-14 12:50 ` Chet Ramey 2017-09-14 13:21 ` Steffen Nurpmeso 1 sibling, 1 reply; 204+ messages in thread From: Rico Pajarola @ 2017-09-14 12:13 UTC (permalink / raw) On Thu, Sep 14, 2017 at 1:11 PM, <arnold at skeeve.com> wrote: > Rico Pajarola <rp at servium.ch> wrote: > > But on modern Linux? That's not my experience. Maybe we just have > different > > standards for "just works", but a typical "modern" open source project > > nowadays "just works" (for my definition of just works) on pretty much > any > > modern system including FreeBSD (type: ./configure; make && make > install). > > Like anything else, it depends on the quality, knowledge, and experience > of the developers. The problem isn't really the Autotools as much as > inexperienced developers who don't understand that all the world is not > Linux and who thus feel free to assume way too many things. > > We just went through the exercise of building the latest libpcap for > Linux, Solaris, AIX and HP-UX. Nightmarish, due to dependency upon > flex, which in turn took an act of Congress in order to get it to build, > particularly on AIX, but also not so easy on the others. > > OTOH, the older GNU projects, with experienced developers (gawk, Bash) > don't exhibit such issues. > True, I'm amazed every time I try a really old version of some old GNU software like bash 1.0 on a contemporary (but unusual) OS. No errors, no warnings, nothing to fix-up manually. It just works. My two cents (as one of those battle-scarred developers :-) > ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/9f73e264/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 12:13 ` Rico Pajarola @ 2017-09-14 12:50 ` Chet Ramey 2017-09-14 13:27 ` Rico Pajarola 0 siblings, 1 reply; 204+ messages in thread From: Chet Ramey @ 2017-09-14 12:50 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 576 bytes --] On 9/14/17 8:13 AM, Rico Pajarola wrote: > True, I'm amazed every time I try a really old version of some old GNU > software like bash 1.0 on a contemporary (but unusual) OS. No errors, no > warnings, nothing to fix-up manually. It just works. If you have a version of bash-1.0, send it my way. We weren't quite as careful with preserving milestone software versions in those days. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://cnswww.cns.cwru.edu/~chet/ ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 12:50 ` Chet Ramey @ 2017-09-14 13:27 ` Rico Pajarola 2017-09-14 14:30 ` Chet Ramey 0 siblings, 1 reply; 204+ messages in thread From: Rico Pajarola @ 2017-09-14 13:27 UTC (permalink / raw) On Thu, Sep 14, 2017 at 2:50 PM, Chet Ramey <chet.ramey at case.edu> wrote: > On 9/14/17 8:13 AM, Rico Pajarola wrote: > > > True, I'm amazed every time I try a really old version of some old GNU > > software like bash 1.0 on a contemporary (but unusual) OS. No errors, no > > warnings, nothing to fix-up manually. It just works. > > If you have a version of bash-1.0, send it my way. We weren't quite as > careful with preserving milestone software versions in those days. > it wasn't *exactly* 1.0 The oldest version I can find with by running "locate bash-1.0" on my datagrave is version 1.05. Do you keep an archive of old software somewhere? I spend a lot of time hunting down old versions of 90'ies era software, but it's becoming increasingly frustrating due to ftp services being turned down, especially at universities. > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet at case.edu http://cnswww.cns.cwru.edu/~ > chet/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/bec7c4a3/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 13:27 ` Rico Pajarola @ 2017-09-14 14:30 ` Chet Ramey 0 siblings, 0 replies; 204+ messages in thread From: Chet Ramey @ 2017-09-14 14:30 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1031 bytes --] On 9/14/17 9:27 AM, Rico Pajarola wrote: > If you have a version of bash-1.0, send it my way. We weren't quite as > careful with preserving milestone software versions in those days. > > it wasn't *exactly* 1.0 > > The oldest version I can find with by running "locate bash-1.0" on my > datagrave is version 1.05. I have 1.05; it's the oldest version I have ever found. > Do you keep an archive of old software somewhere? I spend a lot of time > hunting down old versions of 90'ies era software, but it's becoming > increasingly frustrating due to ftp services being turned down, especially > at universities. I'm only interested in old versions of bash, sorry. I don't really keep an extensive collection of old software available (though I believe I have the only ftp-available version of the original ash sources). Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://cnswww.cns.cwru.edu/~chet/ ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 11:11 ` arnold 2017-09-14 12:13 ` Rico Pajarola @ 2017-09-14 13:21 ` Steffen Nurpmeso 2017-09-14 19:44 ` arnold 2017-09-14 20:31 ` Ian Zimmerman 1 sibling, 2 replies; 204+ messages in thread From: Steffen Nurpmeso @ 2017-09-14 13:21 UTC (permalink / raw) arnold at skeeve.com wrote: |Rico Pajarola <rp at servium.ch> wrote: | |> I also wept a bit when reading this. I once built gnome from source (don't |> ask why), on Solaris, IRIX, and HP-UX. That was also the month I learned |> how to use "autoconf" and "libtool" as swearwords... | |Libtool for sure. Autoconf is something you have to come to a negotiated |truce with and then it's OK. :-) I cannot seem to reach that state. I see that the m4 directory of gawk v4.1.4 contains no less than 46 files with a total of 312 KB. On top of that the root directory contains some configure related files which sum up to about 500 KB. I do not know how much manual work was necessary for the files in m4, as i never have used autotools (except for a week or so doing something -- now obsolete -- for groff, there m4/groff.m4 is about 50 KB and handcraft). And when i look into the missing_d of gawk i cannot help to wonder what all that is for. But of course, what is the alternative? My MUA has a handcrafted 75 KB config shell script but the make system no longer could install: on e.g. UnixWare v7.1.4 because of problems of the system make last time i tried (we could outsource that as a shell script and simply invoke that though), it does not work on the Solaris 9 i have access to (via OpenCSW.org) because we cannot work around a SIZE_MAX iirc that is only defined but to nothing etc. etc. etc. |> But on modern Linux? That's not my experience. Maybe we just have \ |> different |> standards for "just works", but a typical "modern" open source project |> nowadays "just works" (for my definition of just works) on pretty much any |> modern system including FreeBSD (type: ./configure; make && make install). | |Like anything else, it depends on the quality, knowledge, and experience |of the developers. The problem isn't really the Autotools as much as |inexperienced developers who don't understand that all the world is not |Linux and who thus feel free to assume way too many things. | |We just went through the exercise of building the latest libpcap for |Linux, Solaris, AIX and HP-UX. Nightmarish, due to dependency upon |flex, which in turn took an act of Congress in order to get it to build, |particularly on AIX, but also not so easy on the others. | |OTOH, the older GNU projects, with experienced developers (gawk, Bash) |don't exhibit such issues. Plan9 shows an impressive beauty regarding this topic, but it, of course, is exclusive to a current Plan9. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 13:21 ` Steffen Nurpmeso @ 2017-09-14 19:44 ` arnold 2017-09-14 20:22 ` [TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ] Jon Steinhart 2017-09-15 17:42 ` [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] Steffen Nurpmeso 2017-09-14 20:31 ` Ian Zimmerman 1 sibling, 2 replies; 204+ messages in thread From: arnold @ 2017-09-14 19:44 UTC (permalink / raw) Definitely getting off-topic here ... Steffen Nurpmeso <steffen at sdaoden.eu> wrote: > |Libtool for sure. Autoconf is something you have to come to a negotiated > |truce with and then it's OK. :-) > > I cannot seem to reach that state. I see that the m4 directory of > gawk v4.1.4 contains no less than 46 files with a total of 312 KB. > On top of that the root directory contains some configure related > files which sum up to about 500 KB. Gawk is light-weight compared to most projects that use gnulib (e.g, grep). Much of what you point out is boilerplate placed there by the autotools. The only file(s) I, as a developer, have to mess with are the configure.ac files. > I do not know how much manual work was necessary for the files in > m4, Once it's set up, you just ignore it, and update the files whenever there's a new autoconf / automake / gettext / libtool release. I've been using autoconf since 1.x days, so I'm very used to it. I also find it to be much less aggravation than CMake-based projects, where if something craps out during the cmake run, you essentially must wipe out the directory and re-extract the tarball to start over. > And when i look into the missing_d of gawk > i cannot help to wonder what all that is for. Much of it is probably obsolete. Some things date back to the days when some systems had strchr() and others had index()... > But of course, what is the alternative? I don't see one. CMake doesn't really cut it for me. For make problems, port GNU Make; it's very portable, since it's one of the base items for many GNU projects. I know it runs on Solaris 9. > Plan9 shows an impressive beauty regarding this topic, but it, of > course, is exclusive to a current Plan9. No arguments there, but unfortunately, Plan 9 is a very self-contained sandbox. Few of us get to live there all the time. Arnold ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ] 2017-09-14 19:44 ` arnold @ 2017-09-14 20:22 ` Jon Steinhart 2017-09-14 20:32 ` Ron Natalie 2017-09-14 20:41 ` Bakul Shah 2017-09-15 17:42 ` [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] Steffen Nurpmeso 1 sibling, 2 replies; 204+ messages in thread From: Jon Steinhart @ 2017-09-14 20:22 UTC (permalink / raw) OK, not gonna splice in all of the things to which I'm responding. I don't have much love for the libtool/autoconf/automake/etc. system. While it works, and is better than nothing, I have always felt that it was the wrong approach. I am fortunate that I know some of the folks who worked on these tools because they're part of the too complex for casual users thing that I mentioned in my earlier post about open source. I worked for a startup in 1985 that produced CAD tools that needed to run on the various workstations of the era: Daisy, Apollo, Sun, etc. When I started at the company, they would hire a new person to do a port whenever we needed to support a new system. I changed that so that it took someone at most a few hours to do a port. The way that I did this was to have a portability libarary and header file for each target system. We wrote our code for SunOS with the minor difference that each library or system call had a p_ prefix, i.e., p_fopen and so on. The portability library and header mapped each of these into the target system facilities. In most cases this was done by a macro in the header file that just defined p_fopen to be fopen and so on. In the harder cases we had to write actual code to do some translation. I have a faint memory that Apollo had some different arguments to fopen, and at least one of the systems either used carriage return as a line terminator or maybe used CF-LF. There are two big advantages to handling portability this way. First, the source code is easier to read; it's not full of #ifdef this and #ifndef that. Second, once the portability library existed it just worked and could be reused. With the GNU tools methodology, every time someone needed to do a fopen on a machine where the target behaved differently, the alternate code needed to be written. There was no debugged library where this stuff only had to be figured out once. Just my $.02. Jon ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ] 2017-09-14 20:22 ` [TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ] Jon Steinhart @ 2017-09-14 20:32 ` Ron Natalie 2017-09-14 21:00 ` Chris Torek 2017-09-16 3:33 ` Larry McVoy 2017-09-14 20:41 ` Bakul Shah 1 sibling, 2 replies; 204+ messages in thread From: Ron Natalie @ 2017-09-14 20:32 UTC (permalink / raw) Autoconf didn't originate with Gnu. It was around longer than that (someone can probably remember, but I remember some of the netnews software using it long before RMS or LINUX got going). I always havd a lot of distatste for it. I worked on portable software as well, everything form Unipress EMACS to BRL CAD to my own software products (we ran on, let me see if I can recall: SUN both Solaris and the old SunOS4, Stellar, Ardent, HP (both architectures), Apollo, SGI (various levels), DEC MIPS, DEC ALPHA, RS6000, iTanium, i8t0 (several flavors), the 80x86 in many flavors, Intergraph 32032, Intergraph Clipper... We were always able to disttill the portability information into a single set of include files, one conf.h and one included for each platform. Most of the grief came from people with various ideas on how to do 64 bit seeks and of all things (thankfully we got away from this) stty/ioctl. I never had to resort to a script to set things up. Reading down through conf.h told me what my options were and it didn't take long to set things up. I also ported/wrote X11 servers for four or five systems (including writing my own CFB24 before MIT released theres). iMake worked pretty well, though since it relied on the C prepropcessor and the exacxt format of the C preprocessor output really isn't defined for white space, it sometimes was a problem. Eventually, we picked up CMAKE though I don't particularly like that one either. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ] 2017-09-14 20:32 ` Ron Natalie @ 2017-09-14 21:00 ` Chris Torek 2017-09-14 21:03 ` Ron Natalie 2017-09-16 3:34 ` Larry McVoy 2017-09-16 3:33 ` Larry McVoy 1 sibling, 2 replies; 204+ messages in thread From: Chris Torek @ 2017-09-14 21:00 UTC (permalink / raw) >Autoconf didn't originate with Gnu. It was around longer than that >(someone can probably remember, but I remember some of the netnews software >using it long before RMS or LINUX got going). It was not autoconf itself, but Larry Wall's configure scripts were probably an (or "the") inspiration. "Congratulations! You're not running Eunice." Chris ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ] 2017-09-14 21:00 ` Chris Torek @ 2017-09-14 21:03 ` Ron Natalie 2017-09-14 22:26 ` Grant Taylor 2017-09-16 3:34 ` Larry McVoy 1 sibling, 1 reply; 204+ messages in thread From: Ron Natalie @ 2017-09-14 21:03 UTC (permalink / raw) Years ago, I was building an RSX-11M system and it had a rather intricate setup script. At one point it announced: "This will take a while. Go have a cup of coffee." And I useually did. Then one day I was building a machine in another lab and it said: "This will take a while. Go have a cup of tea." OK, I had to dig into the script to figure it out. Turns out the beverage selection was dependent on the configured line frequency. The lab system was built for European deployment (50HZ power). ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ] 2017-09-14 21:03 ` Ron Natalie @ 2017-09-14 22:26 ` Grant Taylor 0 siblings, 0 replies; 204+ messages in thread From: Grant Taylor @ 2017-09-14 22:26 UTC (permalink / raw) On 09/14/2017 03:03 PM, Ron Natalie wrote: > Years ago, I was building an RSX-11M system and it had a rather intricate > setup script. At one point it announced: > > "This will take a while. Go have a cup of coffee." > > And I useually did. Then one day I was building a machine in another lab > and it said: > > "This will take a while. Go have a cup of tea." > > OK, I had to dig into the script to figure it out. Turns out the beverage > selection was dependent on the configured line frequency. The lab system > was built for European deployment (50HZ power). LOL I love the humor that I see in unix programs. I still love to parrot "tar is cowardly refusing to create an empty archive" to people. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3717 bytes Desc: S/MIME Cryptographic Signature URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/6e123c79/attachment-0001.bin> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ] 2017-09-14 21:00 ` Chris Torek 2017-09-14 21:03 ` Ron Natalie @ 2017-09-16 3:34 ` Larry McVoy 2017-09-16 4:16 ` Warner Losh 2017-09-16 5:08 ` Dave Horsfall 1 sibling, 2 replies; 204+ messages in thread From: Larry McVoy @ 2017-09-16 3:34 UTC (permalink / raw) On Thu, Sep 14, 2017 at 02:00:05PM -0700, Chris Torek wrote: > "Congratulations! You're not running Eunice." Heh, I remember that :) And I ran on Eunice back in the day. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ] 2017-09-16 3:34 ` Larry McVoy @ 2017-09-16 4:16 ` Warner Losh 2017-09-16 5:08 ` Dave Horsfall 1 sibling, 0 replies; 204+ messages in thread From: Warner Losh @ 2017-09-16 4:16 UTC (permalink / raw) On Fri, Sep 15, 2017 at 9:34 PM, Larry McVoy <lm at mcvoy.com> wrote: > On Thu, Sep 14, 2017 at 02:00:05PM -0700, Chris Torek wrote: > > "Congratulations! You're not running Eunice." > > Heh, I remember that :) And I ran on Eunice back in the day. > That was a complicated world with the whole TGV vs TWG dueling licenses for TCP on VMS... And despite all that, I never actually ran anything on Eunice... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170915/432c3ff2/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ] 2017-09-16 3:34 ` Larry McVoy 2017-09-16 4:16 ` Warner Losh @ 2017-09-16 5:08 ` Dave Horsfall 1 sibling, 0 replies; 204+ messages in thread From: Dave Horsfall @ 2017-09-16 5:08 UTC (permalink / raw) On Fri, 15 Sep 2017, Larry McVoy wrote: >> "Congratulations! You're not running Eunice." > > Heh, I remember that :) And I ran on Eunice back in the day. I resemble that remark :-) I used to tell a boss that Eunice made VMS look civilised, and he growled back "No, it makes it look like Unix." But that's what I said :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ] 2017-09-14 20:32 ` Ron Natalie 2017-09-14 21:00 ` Chris Torek @ 2017-09-16 3:33 ` Larry McVoy 1 sibling, 0 replies; 204+ messages in thread From: Larry McVoy @ 2017-09-16 3:33 UTC (permalink / raw) +1. BitKeeper runs on a ton of platforms and we have no love nor no need for autoconf. On Thu, Sep 14, 2017 at 04:32:41PM -0400, Ron Natalie wrote: > Autoconf didn't originate with Gnu. It was around longer than that > (someone can probably remember, but I remember some of the netnews software > using it long before RMS or LINUX got going). > I always havd a lot of distatste for it. I worked on portable software > as well, everything form Unipress EMACS to BRL CAD to my own software > products (we ran on, let me see if I can recall: SUN both Solaris and the > old SunOS4, Stellar, Ardent, HP (both architectures), Apollo, SGI (various > levels), DEC MIPS, DEC ALPHA, RS6000, iTanium, i8t0 (several flavors), the > 80x86 in many flavors, Intergraph 32032, Intergraph Clipper... > > We were always able to disttill the portability information into a single > set of include files, one conf.h and one included for each platform. Most > of the grief came from people with various ideas on how to do 64 bit seeks > and of all things (thankfully we got away from this) stty/ioctl. > > I never had to resort to a script to set things up. Reading down through > conf.h told me what my options were and it didn't take long to set things > up. > > I also ported/wrote X11 servers for four or five systems (including writing > my own CFB24 before MIT released theres). iMake worked pretty well, > though since it relied on the C prepropcessor and the exacxt format of the C > preprocessor output really isn't defined for white space, it sometimes was a > problem. Eventually, we picked up CMAKE though I don't particularly like > that one either. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ] 2017-09-14 20:22 ` [TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ] Jon Steinhart 2017-09-14 20:32 ` Ron Natalie @ 2017-09-14 20:41 ` Bakul Shah 2017-09-14 21:00 ` Noel Hunt 1 sibling, 1 reply; 204+ messages in thread From: Bakul Shah @ 2017-09-14 20:41 UTC (permalink / raw) On Sep 14, 2017, at 1:22 PM, Jon Steinhart <jon at fourwinds.com> wrote: > > I don't have much love for the libtool/autoconf/automake/etc. system. > While it works, and is better than nothing, I have always felt that > it was the wrong approach. I am fortunate that I know some of the > folks who worked on these tools because they're part of the too complex > for casual users thing that I mentioned in my earlier post about open > source. My days of wrestling with libtool/autoconf/automake/cmake are mostly in the past. On FreeBSD/MacOS I use pkg/brew. For any new coding I mainly use Go. Even cross compiled binaries just work. It has a very well engineered ecosystem. > There are two big advantages to handling portability this way. First, the > source code is easier to read; it's not full of #ifdef this and #ifndef that. > Second, once the portability library existed it just worked and could be > reused. With the GNU tools methodology, every time someone needed to do a > fopen on a machine where the target behaved differently, the alternate code > needed to be written. There was no debugged library where this stuff only > had to be figured out once. I agree with this. auto{conf,make}/configure is just the wrong approach. At Real Networks our media server ran on 12 or so Unix platforms + windows + macOS9 (at the time). I managed to corral machine dependent code in basically a couple files for all but MacOS9. No #ifdefs in any other file. C++ also helped to hide things like select(2) vs poll(2) from other code. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ] 2017-09-14 20:41 ` Bakul Shah @ 2017-09-14 21:00 ` Noel Hunt 0 siblings, 0 replies; 204+ messages in thread From: Noel Hunt @ 2017-09-14 21:00 UTC (permalink / raw) I'm surprised no-one has mentioned 'iffe', written by Glenn Fowler and Phong Vo who were at AT&T. It is simply a (large) shell script that runs 'feature' files. I have had problems with it on 64-bit builds but I have had far too many problems with 'configure' over the years. 'Iffe' deserves to be better known. On Fri, Sep 15, 2017 at 6:41 AM, Bakul Shah <bakul at bitblocks.com> wrote: > On Sep 14, 2017, at 1:22 PM, Jon Steinhart <jon at fourwinds.com> wrote: > > > > I don't have much love for the libtool/autoconf/automake/etc. system. > > While it works, and is better than nothing, I have always felt that > > it was the wrong approach. I am fortunate that I know some of the > > folks who worked on these tools because they're part of the too complex > > for casual users thing that I mentioned in my earlier post about open > > source. > > My days of wrestling with libtool/autoconf/automake/cmake are mostly > in the past. On FreeBSD/MacOS I use pkg/brew. For any new coding I > mainly use Go. Even cross compiled binaries just work. It has a very > well engineered ecosystem. > > > There are two big advantages to handling portability this way. First, > the > > source code is easier to read; it's not full of #ifdef this and #ifndef > that. > > Second, once the portability library existed it just worked and could be > > reused. With the GNU tools methodology, every time someone needed to do > a > > fopen on a machine where the target behaved differently, the alternate > code > > needed to be written. There was no debugged library where this stuff > only > > had to be figured out once. > > I agree with this. auto{conf,make}/configure is just the wrong approach. > > At Real Networks our media server ran on 12 or so Unix platforms + windows > + > macOS9 (at the time). I managed to corral machine dependent code in > basically > a couple files for all but MacOS9. No #ifdefs in any other file. C++ also > helped to hide things like select(2) vs poll(2) from other code. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170915/da846e48/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 19:44 ` arnold 2017-09-14 20:22 ` [TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ] Jon Steinhart @ 2017-09-15 17:42 ` Steffen Nurpmeso 1 sibling, 0 replies; 204+ messages in thread From: Steffen Nurpmeso @ 2017-09-15 17:42 UTC (permalink / raw) arnold at skeeve.com wrote: |Definitely getting off-topic here ... Do not think so, my i386 had a 20 MB hard disc... |Steffen Nurpmeso <steffen at sdaoden.eu> wrote: |>|Libtool for sure. Autoconf is something you have to come to a negotiated |>|truce with and then it's OK. :-) |> |> I cannot seem to reach that state. I see that the m4 directory of |> gawk v4.1.4 contains no less than 46 files with a total of 312 KB. |> On top of that the root directory contains some configure related |> files which sum up to about 500 KB. | |Gawk is light-weight compared to most projects that use gnulib (e.g, |grep). Much of what you point out is boilerplate placed there by |the autotools. The only file(s) I, as a developer, have to mess with |are the configure.ac files. | |> I do not know how much manual work was necessary for the files in |> m4, | |Once it's set up, you just ignore it, and update the files whenever I only referred to its noise, not the comfort that it brings. |there's a new autoconf / automake / gettext / libtool release. That update rate was quite high in the last years but seems to have settled down again. I became frustrated earlier, and stopped to track many projects which no longer ship a pre-prepared configure file via V-C-S, turning to tar bombs again. That is ugly, but having several versions of those tools around concurrently to satisfy all those projects, no time. |I've been using autoconf since 1.x days, so I'm very used to it. |I also find it to be much less aggravation than CMake-based projects, |where if something craps out during the cmake run, you essentially |must wipe out the directory and re-extract the tarball to start over. I do not know. I once used perl for my configuration stuff, it had to be available for OpenSSL anyway, and it was by default installed on FreeBSD later on, anyway. Also perl configures and compiles out of the box on the Linux/BSD i had, and OpenSSL does if there is perl. So with vim which did not need anything i am ready. |> And when i look into the missing_d of gawk |> i cannot help to wonder what all that is for. | |Much of it is probably obsolete. Some things date back to the days |when some systems had strchr() and others had index()... I hope it will be a fun project some day to port my stuff to elder systems, before FreeBSD 4.7 / Solaris 9 / Linux 2.0.x. Hopefully. And i tend to write such simple functions my own anyway. (I once had the dream to end up with only me and the operating system, but that is long gone.) |> But of course, what is the alternative? | |I don't see one. CMake doesn't really cut it for me. For make |problems, port GNU Make; it's very portable, since it's one of the |base items for many GNU projects. | |I know it runs on Solaris 9. Actually that made me kindly ignore the invalid definition of UINTPTR_MAX and INTPTR_MAX on Solaris 5.9 and also replace a call to iswblank(3) (i do not think it matters that much for now), ending up with another credit of yours for the port to 5.9. It was not about the make(1), actually, only /bin/sh we really cannot afford but require /usr/xpg4/bin. It was MAKEJOBS='-j X' which resulted in -j being ignored and X standing alone and by itself. I never needed GNU make, the perl thing unrolled anything and did not even use inference rules (in fact i did not understand them back then. And was not interested enough to learn!! Terrible.) |> Plan9 shows an impressive beauty regarding this topic, but it, of |> course, is exclusive to a current Plan9. | |No arguments there, but unfortunately, Plan 9 is a very self-contained |sandbox. Few of us get to live there all the time. It is on a descending branch, so to say. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 13:21 ` Steffen Nurpmeso 2017-09-14 19:44 ` arnold @ 2017-09-14 20:31 ` Ian Zimmerman 1 sibling, 0 replies; 204+ messages in thread From: Ian Zimmerman @ 2017-09-14 20:31 UTC (permalink / raw) On 2017-09-14 15:21, Steffen Nurpmeso wrote: > But of course, what is the alternative? scons? The main argument against it seems to be speed (or rather lack of it). The current version has a framework for build-time tests with features quite similar to autotools. Of course there are many fewer pre-packaged tests, but in my experience the pre-packaged tests in autotools are not all that useful, at least not for building on "modern" systems; for the interesting platform differences one needs to write custom auto* macros anyway. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. Do obvious transformation on domain to reply privately _only_ on Usenet. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 0:53 ` Nemo ` (2 preceding siblings ...) 2017-09-14 9:35 ` Rico Pajarola @ 2017-09-15 3:16 ` Dave Horsfall 2017-09-15 3:33 ` Warner Losh ` (2 more replies) 3 siblings, 3 replies; 204+ messages in thread From: Dave Horsfall @ 2017-09-15 3:16 UTC (permalink / raw) On Wed, 13 Sep 2017, Nemo wrote: > Oh, I nearly wept when I read this. Building a typical project nowadays > is so painful -- the makefile works on one particular Linux distro and > woe betide the rest. Ah, well I remember when "make" was first introduced (in PWB?); I thought it was Christmas... Now, even it has to be modified for various platforms. Trivia: what does "make love" say on your system? My Mac boringly says "make: *** No rule to make target `love'. Stop." and the FreeBSD box isn't much better: "make: don't know how to make love. Stop". I don't know what my Penguin laptop says because it's currently switched off. Sigh... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-15 3:16 ` Dave Horsfall @ 2017-09-15 3:33 ` Warner Losh 2017-09-15 8:32 ` Ron Natalie 2017-09-15 12:42 ` Arthur Krewat 2017-09-15 18:20 ` Steffen Nurpmeso 2 siblings, 1 reply; 204+ messages in thread From: Warner Losh @ 2017-09-15 3:33 UTC (permalink / raw) On Thu, Sep 14, 2017 at 9:16 PM, Dave Horsfall <dave at horsfall.org> wrote: > On Wed, 13 Sep 2017, Nemo wrote: > > Oh, I nearly wept when I read this. Building a typical project nowadays >> is so painful -- the makefile works on one particular Linux distro and woe >> betide the rest. >> > > Ah, well I remember when "make" was first introduced (in PWB?); I thought > it was Christmas... > > Now, even it has to be modified for various platforms. > > Trivia: what does "make love" say on your system? My Mac boringly says > "make: *** No rule to make target `love'. Stop." and the FreeBSD box isn't > much better: "make: don't know how to make love. Stop". I don't know what > my Penguin laptop says because it's currently switched off. > > Sigh... FreeBSD's make used to say 'not war' but when bmake was imported from NetBSD, that went away and the maintainers aren't keen on brining back the joke :( I added it years ago, but haven't missed it enough to fight the political battle to get it back in... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/bf9e3d31/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-15 3:33 ` Warner Losh @ 2017-09-15 8:32 ` Ron Natalie 0 siblings, 0 replies; 204+ messages in thread From: Ron Natalie @ 2017-09-15 8:32 UTC (permalink / raw) The command MAKE on TOPS10 was an interface to the editor (TECO). . MAKE LOVE NOT WAR? [4K CORE] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170915/49e94a3f/attachment-0001.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-15 3:16 ` Dave Horsfall 2017-09-15 3:33 ` Warner Losh @ 2017-09-15 12:42 ` Arthur Krewat 2017-09-15 18:20 ` Steffen Nurpmeso 2 siblings, 0 replies; 204+ messages in thread From: Arthur Krewat @ 2017-09-15 12:42 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 885 bytes --] On TOPS-10, "make love" says "Not WAR?" - but unlike UNIX make, it invokes TECO ;) .MAKE LOVE not WAR? *ITHIS IS A TEST $$ *HT$$ THIS IS A TEST * On 9/14/2017 11:16 PM, Dave Horsfall wrote: > On Wed, 13 Sep 2017, Nemo wrote: > >> Oh, I nearly wept when I read this. Building a typical project >> nowadays is so painful -- the makefile works on one particular Linux >> distro and woe betide the rest. > > Ah, well I remember when "make" was first introduced (in PWB?); I thought > it was Christmas... > > Now, even it has to be modified for various platforms. > > Trivia: what does "make love" say on your system? My Mac boringly > says "make: *** No rule to make target `love'. Stop." and the FreeBSD > box isn't much better: "make: don't know how to make love. Stop". I > don't know what my Penguin laptop says because it's currently switched > off. > > Sigh... > ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-15 3:16 ` Dave Horsfall 2017-09-15 3:33 ` Warner Losh 2017-09-15 12:42 ` Arthur Krewat @ 2017-09-15 18:20 ` Steffen Nurpmeso 2017-09-15 18:37 ` Paul Winalski 2 siblings, 1 reply; 204+ messages in thread From: Steffen Nurpmeso @ 2017-09-15 18:20 UTC (permalink / raw) Dave Horsfall <dave at horsfall.org> wrote: |On Wed, 13 Sep 2017, Nemo wrote: |> Oh, I nearly wept when I read this. Building a typical project nowadays |> is so painful -- the makefile works on one particular Linux distro and |> woe betide the rest. | |Ah, well I remember when "make" was first introduced (in PWB?); I thought |it was Christmas... | |Now, even it has to be modified for various platforms. | |Trivia: what does "make love" say on your system? My Mac boringly says |"make: *** No rule to make target `love'. Stop." and the FreeBSD box |isn't much better: "make: don't know how to make love. Stop". I don't |know what my Penguin laptop says because it's currently switched off. | |Sigh... Schily make is even melodramatic and/or digital: ?1[steffen at wales tmp]$ smake love smake: Can't find any source for 'love'. smake: Couldn't make 'love'. ?1[steffen at wales tmp]$ --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-15 18:20 ` Steffen Nurpmeso @ 2017-09-15 18:37 ` Paul Winalski 0 siblings, 0 replies; 204+ messages in thread From: Paul Winalski @ 2017-09-15 18:37 UTC (permalink / raw) > Dave Horsfall <dave at horsfall.org> wrote: > |On Wed, 13 Sep 2017, Nemo wrote: > | > |Trivia: what does "make love" say on your system? It says: Not war? -Paul W. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-12 20:15 ` Steve Johnson 2017-09-13 2:23 ` Larry McVoy @ 2017-09-13 7:30 ` arnold 2017-09-13 13:35 ` Larry McVoy 1 sibling, 1 reply; 204+ messages in thread From: arnold @ 2017-09-13 7:30 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 5367 bytes --] And buried in this story is another reason Unix / BSD people went with Sun --- (if you had the licenses) they would give you source! Even for educational institutions, where I mostly worked, getting source out of DEC / IBM / HP was essentially impossible. Arnold "Steve Johnson" <scj at yaccman.com> wrote: > Funny. From the outside I had a rather different view of why Sun was > successful. > > In 1986 I came to CA to work for what became Ardent/Stardent. We > made the decision to go with Sun disc-less workstations. They got us > more computing power, on paper, for less $$. > > Roughly a quarter of the machines shipped to us were DOA. When we > got them running, the OS had a memory leak and needed to be rebooted > several times a day. The NFS server had the delightful property of > sometimes inserting 1024 zeros into a file it was writing or > serving. (It was so bad that we hacked the OS to check every > executable for 0-blocks in the instruction space and refuse to run > it. This was especially true for the MIPS cross compiler -- 0 was a > NOP on the MIPS, and encountering a block of zeros caused execution to > slide down a slippery slope of NOPs into the middle of some other > routine with a different stack layout, where it proceeded to do the > most mysterious things...) > > We would go out to lunch every day and trash talk Sun up one side and > down the other. And then we would go back to work and order more > Suns. Because THEY UNDERSTOOD WHAT WE NEEDED, and were TRYING TO > GIVE IT TO US. The other manufacturers were selling application > delivery vehicles rather than attempting to support software > development. Eventually we ironed out many of the issues (often by > changing or hacking the code). The only fly in the ointment was the > service department. Dealing with Sun customer service was like > spitting into the wind. We would report the same bug every week and > they swore the bug had not been reported before. The memory leak > problem became so serious that we told them that we would only renew > the service agreement if they would put a date when that would be > fixed. They refused to do so, and we canceled the service contract, > bought a couple of extra Suns for spares, and heaved a sigh of relief. > > Steve > > ----- Original Message ----- > From: "Jon Steinhart" <jon at fourwinds.com> > To:<tuhs at tuhs.org> > Cc: > Sent:Tue, 12 Sep 2017 08:35:24 -0700 > Subject:Re: [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs > dec/apollo --> X and NeWS ] > > arnold at skeeve.com writes: > > > > In particular, the creation of NFS and then the efforts to make it > into > > a de-facto standard (giving away the RPC and XDR code) was a HUGE > thing. > > > > They weren't afraid to swim upstream, either. Even though NeWS > never took > > off (even when combined with an X server), it was an interesting > design, > > ahead of its time even. > > It's interesting that you mention the two of these together. It's my > opinion that the main reason that NeWS failed was because of the > success > of NFS. > > I recall that Apollo was really pissed off by NFS because they felt > that > their token-ring network was better but lost because NFS was given > away. > In hindsight, they were wrong; while the token-ring performed better > in > large networks, the advent of switches made that moot. In any case, > when > NeWS was released nobody except Sun knew how to do the graphics (even > Adobe didn't know how to do it fast for display) and Apollo et. al. > was > worried that Sun would give NeWS away and make it yet another de > facto > standard a la NFS. This led to the formation of the Hamilton Group > which > was a thinly-disguised industry consortium that existed only for the > purpose of making sure that NeWS didn't succeed. > > > DEC, IBM, and HP, all seemed to be playing follow the leader to Sun > for > > many years. > > I mentioned this to a lot of people after Sun died. Few seem to > realize > how much of what became PC manufacturing technology resulted from > innovations > at Sun. > > ron at ronnatalie.com writes: > > > > NeWS had serious issues. However, the same guy who was the NeWS > proponent > > learned from mistakes and the result was the must more successful > Sun > > tehnology: JAVA. > > I'm going to take issue with the above. NeWS had way fewer serious > issues > than X. It's main reason for failure was the coordinated effort to > kill it > from others in the industry. As the guy who single-handedly prevented > X > from becoming an ANSI standard, I'd be happy to start another thread > on > this topic if people are interested. Part of the result of the > Hamilton > Group effort was the misguided attempt to merge X and NeWS which was > a > botched disaster. > > Java is not the result of learning from mistakes in NeWS. I have > joked with > James that I feel that his legacy is being the person who first > realizes that > technology is changing to the point where something can be done using > an > interpreter. If you look at his project history, he's done this many > times. > I think that it's more accurate to say that Java is the result of a > lifetime > of learning from interpreter projects. I fully expect some new > interpreter > to take over AWS sometime soon :-) > > Jon > ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-13 7:30 ` arnold @ 2017-09-13 13:35 ` Larry McVoy 2017-09-13 23:55 ` Dave Horsfall 0 siblings, 1 reply; 204+ messages in thread From: Larry McVoy @ 2017-09-13 13:35 UTC (permalink / raw) Yeah but not the SCCS history. And the source tapes went through Bill Shannon who would grep the source for swear words and other stuff before blessing it. At least that's how it was when I was there. On Wed, Sep 13, 2017 at 01:30:22AM -0600, arnold at skeeve.com wrote: > And buried in this story is another reason Unix / BSD people went with > Sun --- (if you had the licenses) they would give you source! Even for > educational institutions, where I mostly worked, getting source out of > DEC / IBM / HP was essentially impossible. > > Arnold > > "Steve Johnson" <scj at yaccman.com> wrote: > > > Funny.? From the outside I had a rather different view of why Sun was > > successful. > > > > In 1986 I came to CA to work for what became Ardent/Stardent.? We > > made the decision to go with Sun disc-less workstations.? They got us > > more computing power, on paper, for less $$. > > > > Roughly a quarter of the machines shipped to us were DOA.? When we > > got them running, the OS had a memory leak and needed to be rebooted > > several times a day.? The NFS server had the delightful property of > > sometimes inserting 1024 zeros into a file it was writing or > > serving.??? (It was so bad that we hacked the OS to check every > > executable for 0-blocks in the instruction space and refuse to run > > it.? This was especially true for the MIPS cross compiler -- 0 was a > > NOP on the MIPS, and encountering a block of zeros caused execution to > > slide down a slippery slope of NOPs into the middle of some other > > routine with a different stack layout, where it proceeded to do the > > most mysterious things...) > > > > We would go out to lunch every day and trash talk Sun up one side and > > down the other.? And then we would go back to work and order more > > Suns.? Because THEY UNDERSTOOD WHAT WE NEEDED, and were TRYING TO > > GIVE IT TO US.? The other manufacturers were selling application > > delivery vehicles rather than attempting to support software > > development.? Eventually we ironed out many of the issues (often by > > changing or hacking the code).? The only fly in the ointment was the > > service department.? Dealing with Sun customer service was like > > spitting into the wind.? We would report the same bug every week and > > they swore the bug had not been reported before.? The memory leak > > problem became so serious that we told them that we would only renew > > the service agreement if they would put a date when that would be > > fixed.? They refused to do so, and we canceled the service contract, > > bought a couple of extra Suns for spares, and heaved a sigh of relief. > > > > Steve > > > > ----- Original Message ----- > > From: "Jon Steinhart" <jon at fourwinds.com> > > To:<tuhs at tuhs.org> > > Cc: > > Sent:Tue, 12 Sep 2017 08:35:24 -0700 > > Subject:Re: [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs > > dec/apollo --> X and NeWS ] > > > > arnold at skeeve.com writes: > > > > > > In particular, the creation of NFS and then the efforts to make it > > into > > > a de-facto standard (giving away the RPC and XDR code) was a HUGE > > thing. > > > > > > They weren't afraid to swim upstream, either. Even though NeWS > > never took > > > off (even when combined with an X server), it was an interesting > > design, > > > ahead of its time even. > > > > It's interesting that you mention the two of these together. It's my > > opinion that the main reason that NeWS failed was because of the > > success > > of NFS. > > > > I recall that Apollo was really pissed off by NFS because they felt > > that > > their token-ring network was better but lost because NFS was given > > away. > > In hindsight, they were wrong; while the token-ring performed better > > in > > large networks, the advent of switches made that moot. In any case, > > when > > NeWS was released nobody except Sun knew how to do the graphics (even > > Adobe didn't know how to do it fast for display) and Apollo et. al. > > was > > worried that Sun would give NeWS away and make it yet another de > > facto > > standard a la NFS. This led to the formation of the Hamilton Group > > which > > was a thinly-disguised industry consortium that existed only for the > > purpose of making sure that NeWS didn't succeed. > > > > > DEC, IBM, and HP, all seemed to be playing follow the leader to Sun > > for > > > many years. > > > > I mentioned this to a lot of people after Sun died. Few seem to > > realize > > how much of what became PC manufacturing technology resulted from > > innovations > > at Sun. > > > > ron at ronnatalie.com writes: > > > > > > NeWS had serious issues. However, the same guy who was the NeWS > > proponent > > > learned from mistakes and the result was the must more successful > > Sun > > > tehnology: JAVA. > > > > I'm going to take issue with the above. NeWS had way fewer serious > > issues > > than X. It's main reason for failure was the coordinated effort to > > kill it > > from others in the industry. As the guy who single-handedly prevented > > X > > from becoming an ANSI standard, I'd be happy to start another thread > > on > > this topic if people are interested. Part of the result of the > > Hamilton > > Group effort was the misguided attempt to merge X and NeWS which was > > a > > botched disaster. > > > > Java is not the result of learning from mistakes in NeWS. I have > > joked with > > James that I feel that his legacy is being the person who first > > realizes that > > technology is changing to the point where something can be done using > > an > > interpreter. If you look at his project history, he's done this many > > times. > > I think that it's more accurate to say that Java is the result of a > > lifetime > > of learning from interpreter projects. I fully expect some new > > interpreter > > to take over AWS sometime soon :-) > > > > Jon > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-13 13:35 ` Larry McVoy @ 2017-09-13 23:55 ` Dave Horsfall 2017-09-14 0:18 ` Henry Bent 0 siblings, 1 reply; 204+ messages in thread From: Dave Horsfall @ 2017-09-13 23:55 UTC (permalink / raw) On Wed, 13 Sep 2017, Larry McVoy wrote: > Yeah but not the SCCS history. And the source tapes went through Bill > Shannon who would grep the source for swear words and other stuff before > blessing it. At least that's how it was when I was there. I would love to see his list; I might learn a few new words :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-13 23:55 ` Dave Horsfall @ 2017-09-14 0:18 ` Henry Bent 2017-09-14 2:10 ` Larry McVoy 2017-09-14 19:37 ` Steve Johnson 0 siblings, 2 replies; 204+ messages in thread From: Henry Bent @ 2017-09-14 0:18 UTC (permalink / raw) Were there really that many comments that needed censoring? It would be nice to have the idealism to think of Sun as a freewheeling, uncensored alternative to the corporate structure of DEC and IBM, but having seen the "released" source for the early '90s Unix operating systems of all three I never saw anything to indicate that there were censored inline curses anywhere. If anything, the DEC sources are now more informational by virtue of still having a mostly complete changelog in the header. -Henry On 13 September 2017 at 19:55, Dave Horsfall <dave at horsfall.org> wrote: > On Wed, 13 Sep 2017, Larry McVoy wrote: > > Yeah but not the SCCS history. And the source tapes went through Bill >> Shannon who would grep the source for swear words and other stuff before >> blessing it. At least that's how it was when I was there. >> > > I would love to see his list; I might learn a few new words :-) > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will > suffer." > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/750a93d2/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 0:18 ` Henry Bent @ 2017-09-14 2:10 ` Larry McVoy 2017-09-14 19:37 ` Steve Johnson 1 sibling, 0 replies; 204+ messages in thread From: Larry McVoy @ 2017-09-14 2:10 UTC (permalink / raw) I didn't see a lot but Shannon was very sensitive to appearing professional. On Wed, Sep 13, 2017 at 08:18:06PM -0400, Henry Bent wrote: > Were there really that many comments that needed censoring? It would be > nice to have the idealism to think of Sun as a freewheeling, uncensored > alternative to the corporate structure of DEC and IBM, but having seen the > "released" source for the early '90s Unix operating systems of all three I > never saw anything to indicate that there were censored inline curses > anywhere. If anything, the DEC sources are now more informational by > virtue of still having a mostly complete changelog in the header. > > -Henry > > On 13 September 2017 at 19:55, Dave Horsfall <dave at horsfall.org> wrote: > > > On Wed, 13 Sep 2017, Larry McVoy wrote: > > > > Yeah but not the SCCS history. And the source tapes went through Bill > >> Shannon who would grep the source for swear words and other stuff before > >> blessing it. At least that's how it was when I was there. > >> > > > > I would love to see his list; I might learn a few new words :-) > > > > -- > > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will > > suffer." > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 0:18 ` Henry Bent 2017-09-14 2:10 ` Larry McVoy @ 2017-09-14 19:37 ` Steve Johnson 2017-09-14 19:54 ` Steve Nickolas ` (2 more replies) 1 sibling, 3 replies; 204+ messages in thread From: Steve Johnson @ 2017-09-14 19:37 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2090 bytes --] I'm not aware of any profanity per se in the early Unix sources, but there certainly were some snarky error messages. Like "eh?" Or "Very Funny". I contributed a few: "gummy structure". I've become truly PO'd at the state of error messages in today's software. Things like "file error" or "cannot open file" without telling you what file was being opened. And every encounter with git gives me additional fodder. The information in many of git's error messages is roughly one bit, that is best translated with profanity. I wrote a paper on error messages at one point. I had examples from bad to best. In a nutshell (worst to best): * <program aborts, leaving the world in an unknown state> * "internal error", "beta table overflow", "operation failed" * "Writing the output file failed" * "File xxx could not be opened for writing." * "File xxx could not be opened for writing: check the file location and permissions" * "Writing the output file xxx caused an error. See <link> for possible reasons and corrections" Most git messages fall between 2 and 3. But there are occasional 4's and 5's. Steve ----- Original Message ----- From: "Henry Bent" <henry.r.bent@gmail.com> To:"The Eunuchs Hysterical Society" <tuhs at tuhs.org> Cc: Sent:Wed, 13 Sep 2017 20:18:06 -0400 Subject:Re: [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] Were there really that many comments that needed censoring? It would be nice to have the idealism to think of Sun as a freewheeling, uncensored alternative to the corporate structure of DEC and IBM, but having seen the "released" source for the early '90s Unix operating systems of all three I never saw anything to indicate that there were censored inline curses anywhere. If anything, the DEC sources are now more informational by virtue of still having a mostly complete changelog in the header. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/ffb78d69/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 19:37 ` Steve Johnson @ 2017-09-14 19:54 ` Steve Nickolas 2017-09-14 20:50 ` Ian Zimmerman 2017-09-14 20:11 ` Ron Natalie 2017-09-19 0:52 ` Random832 2 siblings, 1 reply; 204+ messages in thread From: Steve Nickolas @ 2017-09-14 19:54 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1510 bytes --] On Thu, 14 Sep 2017, Steve Johnson wrote: > I'm not aware of any profanity per se in the early Unix sources, but > there certainly were some snarky error messages. Like "eh?" Or > "Very Funny". I contributed a few: "gummy structure". > > I've become truly PO'd at the state of error messages in today's > software. Things like "file error" or "cannot open file" without > telling you what file was being opened. And every encounter with > git gives me additional fodder. The information in many of git's > error messages is roughly one bit, that is best translated with > profanity. > > I wrote a paper on error messages at one point. I had examples from > bad to best. In a nutshell (worst to best): > > * <program aborts, leaving the world in an unknown state> > * "internal error", "beta table overflow", "operation failed" > * "Writing the output file failed" > * "File xxx could not be opened for writing." > * "File xxx could not be opened for writing: check the file location > and permissions" > > * "Writing the output file xxx caused an error. See <link> for > possible reasons and corrections" > > Most git messages fall between 2 and 3. But there are occasional 4's > and 5's. > > Steve You got perror(), use it (not you)... >_> All my code that outputs error messages for stuff in the C library uses perror(), so a typical error might be "foo: cannot open file bar: No such file or directory", with the last part coming from the C runtime itself. -uso. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 19:54 ` Steve Nickolas @ 2017-09-14 20:50 ` Ian Zimmerman 2017-09-14 21:00 ` Ron Natalie 0 siblings, 1 reply; 204+ messages in thread From: Ian Zimmerman @ 2017-09-14 20:50 UTC (permalink / raw) On 2017-09-14 15:54, Steve Nickolas wrote: > You got perror(), use it (not you)... >_> > > All my code that outputs error messages for stuff in the C library > uses perror(), so a typical error might be "foo: cannot open file bar: > No such file or directory", with the last part coming from the C > runtime itself. This only works if you call libc directly, or if the code you call (including your own) reuses libc errno codes. If you deal with libfoo, libfoo has its own error codes, and has no perror-like function, you must write your own :( -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. Do obvious transformation on domain to reply privately _only_ on Usenet. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 20:50 ` Ian Zimmerman @ 2017-09-14 21:00 ` Ron Natalie 0 siblings, 0 replies; 204+ messages in thread From: Ron Natalie @ 2017-09-14 21:00 UTC (permalink / raw) The error codes perror relies on don't come from "libc." They come from the kernel. The values only make sense if the error is the result of a system call. -----Original Message----- This only works if you call libc directly, or if the code you call (including your own) reuses libc errno codes. If you deal with libfoo, libfoo has its own error codes, and has no perror-like function, you must write your own :( . ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 19:37 ` Steve Johnson 2017-09-14 19:54 ` Steve Nickolas @ 2017-09-14 20:11 ` Ron Natalie 2017-09-14 20:26 ` Jon Steinhart 2017-09-19 0:52 ` Random832 2 siblings, 1 reply; 204+ messages in thread From: Ron Natalie @ 2017-09-14 20:11 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1040 bytes --] Ø I'm not aware of any profanity per se in the early Unix sources, but there certainly were some snarky error messages. Like "eh?" Or "Very Funny". I contributed a few: "gummy structure". Of which “You’re not expected to understand this” is probably the most famous. This so incensed my mentor Mike Muuss that he figured out what the code REALLY did and wrote several paragrahs after that starting with “You are expected to understand this:” The worst error system I ever encountered was a summer job I had in college. The system I was using had a package called “reptile” that’s sole diagnostic was “Snake bite at xxxx” where xxxx was the address that the error was detected. I had a crib sheet of what errors corresponded to what addresses, but that was rendered incorrect when the program was relinked and evertying moved. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/fb405b91/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 20:11 ` Ron Natalie @ 2017-09-14 20:26 ` Jon Steinhart 0 siblings, 0 replies; 204+ messages in thread From: Jon Steinhart @ 2017-09-14 20:26 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1034 bytes --] "Ron Natalie" writes: > The worst error system I ever encountered was a summer job I had in college. > The system I was using had a package called “reptile” that’s sole diagnostic > was “Snake bite at xxxx” where xxxx was the address that the error was > detected. I had a crib sheet of what errors corresponded to what addresses, > but that was rendered incorrect when the program was relinked and evertying > moved. I suppose that I'm guilty of this at some level. When I worked at Tektronix there was a management edict that one had to check for error returns on all system calls even if the only way in which the system call would fail was because the system was in the process of crashing. I don't remember the exact specifics, but it annoyed me to be wasting valuable space doing this, and there was some sort of ioctl on a tty that could not possibly fail on a healthy system and wouldn't cause any damage even if the error was returned. While nobody ever saw it, I chose the error message "tough ttys". ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 19:37 ` Steve Johnson 2017-09-14 19:54 ` Steve Nickolas 2017-09-14 20:11 ` Ron Natalie @ 2017-09-19 0:52 ` Random832 2017-09-19 2:50 ` Larry McVoy 2 siblings, 1 reply; 204+ messages in thread From: Random832 @ 2017-09-19 0:52 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1138 bytes --] On Thu, Sep 14, 2017, at 15:37, Steve Johnson wrote: > I wrote a paper on error messages at one point. I had examples from > bad to best. In a nutshell (worst to best): > > * <program aborts, leaving the world in an unknown state> > * "internal error", "beta table overflow", "operation failed" > * "Writing the output file failed" > * "File xxx could not be opened for writing." > * "File xxx could not be opened for writing: check the file location > and permissions" > > * "Writing the output file xxx caused an error. See <link> for > possible reasons and corrections" > > Most git messages fall between 2 and 3. But there are occasional 4's > and 5's. Just out of curiosity, where does perror(filename), quite possibly the *most* common error message on Unix as a whole, fall on your scale? It says which of the file location or permissions (or whatever else) it is, but not whether it was attempting to open it for reading or writing. (Of course, git sometimes has the problem that other cases of a 4 or 5 don't: needing to understand its internal structure to know why it wants that file and how to fix it.) ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-19 0:52 ` Random832 @ 2017-09-19 2:50 ` Larry McVoy 2017-09-19 2:56 ` Gregg Levine ` (3 more replies) 0 siblings, 4 replies; 204+ messages in thread From: Larry McVoy @ 2017-09-19 2:50 UTC (permalink / raw) On Mon, Sep 18, 2017 at 08:52:08PM -0400, Random832 wrote: > On Thu, Sep 14, 2017, at 15:37, Steve Johnson wrote: > > I wrote a paper on error messages at one point.?? I had examples from > > bad to best.?? In a nutshell (worst to best): > > > > * <program aborts, leaving the world in an unknown state> > > * "internal error",?? "beta table overflow", "operation failed" > > * "Writing the output file failed" > > * "File xxx could not be opened for writing." > > * "File xxx could not be opened for writing: check the file location > > and permissions" > > > > * "Writing the output file xxx caused an error.?? See <link> for > > possible reasons and corrections" > > > > Most git messages fall between 2 and 3.?? But there are occasional 4's > > and 5's. > > Just out of curiosity, where does perror(filename), quite possibly the > *most* common error message on Unix as a whole, fall on your scale? It > says which of the file location or permissions (or whatever else) it is, > but not whether it was attempting to open it for reading or writing. So in the BitKeeper source, perror is redifined to my_perror which is this: void my_perror(char *file, int line, char *msg) { char *p = 0; int save = errno; if (p = getenv("_BK_VERSION")) { if (strneq(p, "bk-", 3)) p += 3; fprintf(stderr, "%s:%d (%s): ", file, line, p); } else { fprintf(stderr, "%s:%d: ", file, line); } if (p = strerror(errno)) { fprintf(stderr, "%s: %s\n", msg, p); } else { fprintf(stderr, "%s: errno=%d\n", msg, errno); } errno = save; } libc should do that. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-19 2:50 ` Larry McVoy @ 2017-09-19 2:56 ` Gregg Levine 2017-09-19 3:37 ` Larry McVoy 2017-09-19 7:22 ` Ian Zimmerman ` (2 subsequent siblings) 3 siblings, 1 reply; 204+ messages in thread From: Gregg Levine @ 2017-09-19 2:56 UTC (permalink / raw) Hello! Larry, back when I was a serious Kernel Hacker, I actually obtained the appropriate release of Bitkeeper for grabbing the raw source code for the kernel that Linus wrote. I found it much easier to use then what is in use now. Its few errors thrown in my direction were easier to understand then the many thrown at me by the current tool. And here's a hint, even his Foundation and my current distribution author, does not like it much. And I remember meeting a DG system running a release of DG/UX, suffice to say I wasn't happy. I found that the SUN systems running either early Solaris or SUNos were easier to get along with. I can;t recall outside of the VCF East event if I've seen a Tek graphics terminal before........ ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Mon, Sep 18, 2017 at 10:50 PM, Larry McVoy <lm at mcvoy.com> wrote: > On Mon, Sep 18, 2017 at 08:52:08PM -0400, Random832 wrote: >> On Thu, Sep 14, 2017, at 15:37, Steve Johnson wrote: >> > I wrote a paper on error messages at one point.?? I had examples from >> > bad to best.?? In a nutshell (worst to best): >> > >> > * <program aborts, leaving the world in an unknown state> >> > * "internal error",?? "beta table overflow", "operation failed" >> > * "Writing the output file failed" >> > * "File xxx could not be opened for writing." >> > * "File xxx could not be opened for writing: check the file location >> > and permissions" >> > >> > * "Writing the output file xxx caused an error.?? See <link> for >> > possible reasons and corrections" >> > >> > Most git messages fall between 2 and 3.?? But there are occasional 4's >> > and 5's. >> >> Just out of curiosity, where does perror(filename), quite possibly the >> *most* common error message on Unix as a whole, fall on your scale? It >> says which of the file location or permissions (or whatever else) it is, >> but not whether it was attempting to open it for reading or writing. > > So in the BitKeeper source, perror is redifined to my_perror which is > this: > > void > my_perror(char *file, int line, char *msg) > { > char *p = 0; > int save = errno; > > if (p = getenv("_BK_VERSION")) { > if (strneq(p, "bk-", 3)) p += 3; > fprintf(stderr, "%s:%d (%s): ", file, line, p); > } else { > fprintf(stderr, "%s:%d: ", file, line); > } > if (p = strerror(errno)) { > fprintf(stderr, "%s: %s\n", msg, p); > } else { > fprintf(stderr, "%s: errno=%d\n", msg, errno); > } > errno = save; > } > > libc should do that. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-19 2:56 ` Gregg Levine @ 2017-09-19 3:37 ` Larry McVoy 2017-09-19 6:52 ` Lars Brinkhoff 0 siblings, 1 reply; 204+ messages in thread From: Larry McVoy @ 2017-09-19 3:37 UTC (permalink / raw) On Mon, Sep 18, 2017 at 10:56:51PM -0400, Gregg Levine wrote: > Hello! > Larry, back when I was a serious Kernel Hacker, I actually obtained > the appropriate release of Bitkeeper for grabbing the raw source code > for the kernel that Linus wrote. > > I found it much easier to use then what is in use now. Its few errors > thrown in my direction were easier to understand then the many thrown > at me by the current tool. yeah, git suffers from the Not Unix problem that Linux has. There is a lot of value in the Unix approach which is, in my opinion, fairly terse. Do a little but do it right. Don't go crazy with every option that every well intentioned person wants, do the subset that is what people truly want even if they don't realize it. I know it doesn't matter at this point, git won, but BitKeeper is open source under the very liberal Apache license (and if you don't like that one for a good reason I can rerelease under a different license) and there is a ton of useful stuff in there that has nothing to do with source management. Most of perl/lisp is in there, cross platform stuff that includes windows is in there, some pretty amazing stdio work that I wish Chris Torek would suck back into NetBSD is in there, and BK itself is pretty sweet. I routinely do git -C git-repo fast-export master | bk fast-import bk-repo so I can look at the source with BK tools. BK differs from git in many ways, but to you Unix people, BK has the inode concept. There is a thing that is a file, it doesn't care where it lives, the pathname is an attribute of the file, just like the changes are. Git doesn't have a file concept, no inode for you. So no create/unlink/rename, Git doesn't have those, BitKeeper does. In practice that hurts, sometimes a lot, in a big repo git blame is useless because it is so slow, bk's blame runs in milliseconds. And can we talk about merges? Git has one graph for the entire repository. BitKeeper has a graph for each inode. So when Git goes to merge it's going to use the GCA for the repository for everything. BitKeeper uses the GCA for the file which is always a better choice. And BK uses a ton more info, go read the code, it's cool, way better than diff3. I weep when I look at Git. It's just crap yet that is what the world uses. It's exactly what I predicted when I was arguing with the FSF, if you want everything to be free then what you will get is substandard stuff. Not all the time but most of the time. Part of the reason I love this list is it is full of people who were careful, they cared about the code (look at the good taste thread) and they cared about regressions, they cared that people could understand what they did. (And, for the record, I just love love love the stories about the history, Mr Yacc has some great ones, Clem has great ones, all you guys rock when you are talking about how you made something work.) While I use Linux, I yearn for the days where you guys and the SunOS guys were carefully, very carefully, creating a decent system that had an architecture that you could see if you looked hard enough. Unix had that, I'm not sure Linux and friends does. --lm If you want the BK source it's at bitkeeper.org ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-19 3:37 ` Larry McVoy @ 2017-09-19 6:52 ` Lars Brinkhoff 0 siblings, 0 replies; 204+ messages in thread From: Lars Brinkhoff @ 2017-09-19 6:52 UTC (permalink / raw) Larry McVoy wrote: > BitKeeper is open source under the very liberal Apache license [...] > and there is a ton of useful stuff in there that has nothing to do > with source management. Most of perl/lisp is in there Just curious, what Lisp is in there? ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-19 2:50 ` Larry McVoy 2017-09-19 2:56 ` Gregg Levine @ 2017-09-19 7:22 ` Ian Zimmerman 2017-09-19 13:22 ` Larry McVoy 2017-09-19 13:53 ` Steffen Nurpmeso 2017-09-19 14:32 ` Clem Cole 3 siblings, 1 reply; 204+ messages in thread From: Ian Zimmerman @ 2017-09-19 7:22 UTC (permalink / raw) On 2017-09-18 19:50, Larry McVoy wrote: > So in the BitKeeper source, perror is redifined to my_perror which is > this: > > void > my_perror(char *file, int line, char *msg) That is a different signature from perror, so I presume you mean you did something along the lines of #define perror(s) (my_perror(__FILE__, __LINE__, (s))) Since this must obviously be a macro, I'm not sure I want it in libc; macros are messy. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. Do obvious transformation on domain to reply privately _only_ on Usenet. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-19 7:22 ` Ian Zimmerman @ 2017-09-19 13:22 ` Larry McVoy 0 siblings, 0 replies; 204+ messages in thread From: Larry McVoy @ 2017-09-19 13:22 UTC (permalink / raw) On Tue, Sep 19, 2017 at 12:22:14AM -0700, Ian Zimmerman wrote: > On 2017-09-18 19:50, Larry McVoy wrote: > > > So in the BitKeeper source, perror is redifined to my_perror which is > > this: > > > > void > > my_perror(char *file, int line, char *msg) > > That is a different signature from perror, so I presume you mean you did > something along the lines of > > #define perror(s) (my_perror(__FILE__, __LINE__, (s))) Yep. It's much nicer knowing where in the source the error is coming from. Personally, I think this should be the libc version but I'm weird :) ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-19 2:50 ` Larry McVoy 2017-09-19 2:56 ` Gregg Levine 2017-09-19 7:22 ` Ian Zimmerman @ 2017-09-19 13:53 ` Steffen Nurpmeso 2017-09-19 13:56 ` Larry McVoy 2017-09-19 14:32 ` Clem Cole 3 siblings, 1 reply; 204+ messages in thread From: Steffen Nurpmeso @ 2017-09-19 13:53 UTC (permalink / raw) Larry McVoy <lm at mcvoy.com> wrote: |On Mon, Sep 18, 2017 at 08:52:08PM -0400, Random832 wrote: |> On Thu, Sep 14, 2017, at 15:37, Steve Johnson wrote: |>> I wrote a paper on error messages at one point.?? I had examples from |>> bad to best.?? In a nutshell (worst to best): |>> |>> * <program aborts, leaving the world in an unknown state> |>> * "internal error",?? "beta table overflow", "operation failed" |>> * "Writing the output file failed" |>> * "File xxx could not be opened for writing." |>> * "File xxx could not be opened for writing: check the file location |>> and permissions" |>> |>> * "Writing the output file xxx caused an error.?? See <link> for |>> possible reasons and corrections" |>> |>> Most git messages fall between 2 and 3.?? But there are occasional 4's |>> and 5's. |> |> Just out of curiosity, where does perror(filename), quite possibly the |> *most* common error message on Unix as a whole, fall on your scale? It |> says which of the file location or permissions (or whatever else) it is, |> but not whether it was attempting to open it for reading or writing. | |So in the BitKeeper source, perror is redifined to my_perror which is |this: | |void |my_perror(char *file, int line, char *msg) |{ | char *p = 0; | int save = errno; | | if (p = getenv("_BK_VERSION")) { | if (strneq(p, "bk-", 3)) p += 3; | fprintf(stderr, "%s:%d (%s): ", file, line, p); |} else { | fprintf(stderr, "%s:%d: ", file, line); |} | if (p = strerror(errno)) { | fprintf(stderr, "%s: %s\n", msg, p); |} else { | fprintf(stderr, "%s: errno=%d\n", msg, errno); |} | errno = save; |} | |libc should do that. That really made me wonder why "save" is not used, errno may eventually change along the way. Ok ok, but.. well. I have had a Txt::FormatEncoder which was the sole implementation of a format codec (plus FormatDecoder), which supported %m * "%m" * Print the description of the \SF Errno which was active at setup() time, * if it's value has an assigned description * (otherwise a message is printed which says that this value is unknown). * This always prints the original english string \ldots mostly for debugging and developers thus, but why not, except for inter-dependencies, thus optional at least, support of a # modifier could have been added. The encoder could be used for finite (CP::) as well as resizable buffers (CString, ([Sys::]IO::TextWriter, etc.) as in static void _MyAddVFmt( CString &_str, const char *_fmt, void *_valist) { ui32 grow, olen; auto Txt::FormatEncoder fe; // use special case+update() for better code flow (void)fe.setup(NIL, 0, _fmt, _valist); for(grow=80-1; ; ) { olen = _str.length(); (void)fe.update(_str.reserve(grow).data()+olen, grow) .call(); // resize insufficient? nothing changed! if(fe.isInsufficient()) { (void)_str.truncate(olen); grow <<= 1; } else { (void)_str.truncate(olen + fe.count()); if(fe.isFinished()) break; grow = 80-1; } } return; } Terrible: no overflow protection. And camel case. Plus a [Sys::]Log and [Sys::]Log::Domain with vWrite() and pub static void write(Priority _prio, const char *_fmt, ...); That was for the builtin Domain only, which needs to be created to overcome the no-op state, optionally SMP safe: pub static void createBuiltinDomain(IO::Device *_dev, SMP::Mutex *_mtx=NIL); pub static Domain *getBuiltinDomain(void){ return(s_bdom); } Optionally in [Sys::]POSIX there also was pub static Log::Domain *createSyslogDomain( SyslogFacility _facility=user, boolean _includepid=tru1, const char *_intro=NIL, boolean _enabled=tru1, Log::Priority _prio=Log::debug); but that cannot be used as the main log domain. I have forgotten why. It also used a shared internal socket connection and mutex for all domains created like that, but can (re)use CP::fromVFormat() to actually prepare the written messages in the 1 KB stack buffer for syslog purposes. At least. All this of course very inconvenient in a main(): Mem::Cache::enableStatistics(); Mem::Cache::configure(Mem::Cache::conf_trash, tru1); Std::createChannels(tru1, tru1, tru1); No standard streams by default. Log::setEnabled(tru1); Log::setPriority(Log::debug); Log::createBuiltinDomain(Std::ferr); No logging by default. (void)Misc::NYD::setDumpChannel(Std::ferr); And NotYetDead chirps or profiling needs to be charged, too. But despite all faulty design decisions, implementation shortcomings, missing focus on security details, etc., at least you can exactly specify what is going on. And get that and nothing else. Unfortunately C++ has become overly huge, and i am not rich enough to go for a C+ / C-- / C-w-C. Well. There is i think a German who did something i think nice, Python style source code, transformed to C which then is compilable as such. But with garbage collection and all that stuff that interpreted languages ship, and inclusive a runtime. Now called Nim, Nimrod no longer. I have just looked, in the meantime also compiles to JavaScript. Getting real grip it seems, on github etc. Well. Never used it, but sounds very interesting to me. The NetBSD getenv() uses a fast tree i think to speed up lookups. I think especially in massive parallel object-based programs any sort of perror() is likely overchallenged and needs to attach to more context. Then again i have no idea better than "CTX1: CTX2: CTX3: message" either, and always get a headache when i see OpenSSL error messages which exactly go this route. So you need two programs, one to do the work, and the other to interpret the error messages of the first... --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-19 13:53 ` Steffen Nurpmeso @ 2017-09-19 13:56 ` Larry McVoy 2017-09-19 17:56 ` Random832 0 siblings, 1 reply; 204+ messages in thread From: Larry McVoy @ 2017-09-19 13:56 UTC (permalink / raw) On Tue, Sep 19, 2017 at 03:53:59PM +0200, Steffen Nurpmeso wrote: > Larry McVoy <lm at mcvoy.com> wrote: > |On Mon, Sep 18, 2017 at 08:52:08PM -0400, Random832 wrote: > |> On Thu, Sep 14, 2017, at 15:37, Steve Johnson wrote: > |>> I wrote a paper on error messages at one point.?? I had examples from > |>> bad to best.?? In a nutshell (worst to best): > |>> > |>> * <program aborts, leaving the world in an unknown state> > |>> * "internal error",?? "beta table overflow", "operation failed" > |>> * "Writing the output file failed" > |>> * "File xxx could not be opened for writing." > |>> * "File xxx could not be opened for writing: check the file location > |>> and permissions" > |>> > |>> * "Writing the output file xxx caused an error.?? See <link> for > |>> possible reasons and corrections" > |>> > |>> Most git messages fall between 2 and 3.?? But there are occasional 4's > |>> and 5's. > |> > |> Just out of curiosity, where does perror(filename), quite possibly the > |> *most* common error message on Unix as a whole, fall on your scale? It > |> says which of the file location or permissions (or whatever else) it is, > |> but not whether it was attempting to open it for reading or writing. > | > |So in the BitKeeper source, perror is redifined to my_perror which is > |this: > | > |void > |my_perror(char *file, int line, char *msg) > |{ > | char *p = 0; > | int save = errno; > | > | if (p = getenv("_BK_VERSION")) { > | if (strneq(p, "bk-", 3)) p += 3; > | fprintf(stderr, "%s:%d (%s): ", file, line, p); > |} else { > | fprintf(stderr, "%s:%d: ", file, line); > |} > | if (p = strerror(errno)) { > | fprintf(stderr, "%s: %s\n", msg, p); > |} else { > | fprintf(stderr, "%s: errno=%d\n", msg, errno); > |} > | errno = save; > |} > | > |libc should do that. > > That really made me wonder why "save" is not used, errno may > eventually change along the way. Ok ok, but.. well. Huh? save is set with errno and then errno is restored to save. The point of save is to do the library calls (which do syscalls which could in theory change errno) and leave it the same as it was on the way in. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-19 13:56 ` Larry McVoy @ 2017-09-19 17:56 ` Random832 2017-09-19 18:31 ` Steffen Nurpmeso ` (2 more replies) 0 siblings, 3 replies; 204+ messages in thread From: Random832 @ 2017-09-19 17:56 UTC (permalink / raw) On Tue, Sep 19, 2017, at 09:56, Larry McVoy wrote: > On Tue, Sep 19, 2017 at 03:53:59PM +0200, Steffen Nurpmeso wrote: > > |void > > |my_perror(char *file, int line, char *msg) > > |{ > > | char *p = 0; > > | int save = errno; > > | > > | if (p = getenv("_BK_VERSION")) { > > | if (strneq(p, "bk-", 3)) p += 3; > > | fprintf(stderr, "%s:%d (%s): ", file, line, p); > > |} else { > > | fprintf(stderr, "%s:%d: ", file, line); > > |} > > | if (p = strerror(errno)) { > > | fprintf(stderr, "%s: %s\n", msg, p); > > |} else { > > | fprintf(stderr, "%s: errno=%d\n", msg, errno); > > |} > > | errno = save; > > |} > > | > > |libc should do that. > > > > That really made me wonder why "save" is not used, errno may > > eventually change along the way. Ok ok, but.. well. > > Huh? save is set with errno and then errno is restored to save. The > point of save is to do the library calls (which do syscalls which > could in theory change errno) and leave it the same as it was on > the way in. I think his point was that you should be passing save (rather than errno) to the strerror and the last printf, because the preceding library calls may have changed errno. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-19 17:56 ` Random832 @ 2017-09-19 18:31 ` Steffen Nurpmeso 2017-09-19 18:34 ` Larry McVoy 2017-09-19 19:31 ` Lawrence Stewart 2017-09-20 3:13 ` Larry McVoy 2 siblings, 1 reply; 204+ messages in thread From: Steffen Nurpmeso @ 2017-09-19 18:31 UTC (permalink / raw) Random832 <random832 at fastmail.com> wrote: |On Tue, Sep 19, 2017, at 09:56, Larry McVoy wrote: |> On Tue, Sep 19, 2017 at 03:53:59PM +0200, Steffen Nurpmeso wrote: |>>|void |>>|my_perror(char *file, int line, char *msg) |>>|{ |>>| char *p = 0; |>>| int save = errno; |>>| |>>| if (p = getenv("_BK_VERSION")) { |>>| if (strneq(p, "bk-", 3)) p += 3; |>>| fprintf(stderr, "%s:%d (%s): ", file, line, p); |>>|} else { |>>| fprintf(stderr, "%s:%d: ", file, line); |>>|} |>>| if (p = strerror(errno)) { |>>| fprintf(stderr, "%s: %s\n", msg, p); |>>|} else { |>>| fprintf(stderr, "%s: errno=%d\n", msg, errno); |>>|} |>>| errno = save; |>>|} |>>| |>>|libc should do that. |>> |>> That really made me wonder why "save" is not used, errno may |>> eventually change along the way. Ok ok, but.. well. |> |> Huh? save is set with errno and then errno is restored to save. The |> point of save is to do the library calls (which do syscalls which |> could in theory change errno) and leave it the same as it was on |> the way in. | |I think his point was that you should be passing save (rather than |errno) to the strerror and the last printf, because the preceding |library calls may have changed errno. Well, if _you_ see it the WallStreetFighter style then it needs to be said that an overwhelming, deadly, rather exterminating number of points have been made. errno today is thread local storage, or worse some pthread-specific macro expansion, i see multiple call-ins to standard I/O which is potentially SMP-safe, stderr is unbuffered, getenv() can end up doing a sequential walk on a flat array with X number of strncmp() calls, in a context i assume the variable itself is constant over the entire run of the software. Also p=0 is C++ i think. There are two value assignments inside a conditional statement without parenthesis. If the file parameter comes from __FILE__ then that could and likely should be constant string storage, msg looks likewise but possibly not as bad. This code would benefit from an iteration. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-19 18:31 ` Steffen Nurpmeso @ 2017-09-19 18:34 ` Larry McVoy 0 siblings, 0 replies; 204+ messages in thread From: Larry McVoy @ 2017-09-19 18:34 UTC (permalink / raw) On Tue, Sep 19, 2017 at 08:31:52PM +0200, Steffen Nurpmeso wrote: > Random832 <random832 at fastmail.com> wrote: > |On Tue, Sep 19, 2017, at 09:56, Larry McVoy wrote: > |> On Tue, Sep 19, 2017 at 03:53:59PM +0200, Steffen Nurpmeso wrote: > |>>|void > |>>|my_perror(char *file, int line, char *msg) > |>>|{ > |>>| char *p = 0; > |>>| int save = errno; > |>>| > |>>| if (p = getenv("_BK_VERSION")) { > |>>| if (strneq(p, "bk-", 3)) p += 3; > |>>| fprintf(stderr, "%s:%d (%s): ", file, line, p); > |>>|} else { > |>>| fprintf(stderr, "%s:%d: ", file, line); > |>>|} > |>>| if (p = strerror(errno)) { > |>>| fprintf(stderr, "%s: %s\n", msg, p); > |>>|} else { > |>>| fprintf(stderr, "%s: errno=%d\n", msg, errno); > |>>|} > |>>| errno = save; > |>>|} > |>>| > |>>|libc should do that. > |>> > |>> That really made me wonder why "save" is not used, errno may > |>> eventually change along the way. Ok ok, but.. well. > |> > |> Huh? save is set with errno and then errno is restored to save. The > |> point of save is to do the library calls (which do syscalls which > |> could in theory change errno) and leave it the same as it was on > |> the way in. > | > |I think his point was that you should be passing save (rather than > |errno) to the strerror and the last printf, because the preceding > |library calls may have changed errno. > > Well, if _you_ see it the WallStreetFighter style then it needs to > be said that an overwhelming, deadly, rather exterminating number > of points have been made. errno today is thread local storage, or > worse some pthread-specific macro expansion, i see multiple > call-ins to standard I/O which is potentially SMP-safe, stderr is > unbuffered, getenv() can end up doing a sequential walk on a flat > array with X number of strncmp() calls, in a context i assume the > variable itself is constant over the entire run of the software. > Also p=0 is C++ i think. There are two value assignments inside > a conditional statement without parenthesis. If the file > parameter comes from __FILE__ then that could and likely should be > constant string storage, msg looks likewise but possibly not as > bad. This code would benefit from an iteration. > > --steffen Feel free to send in a patch! ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-19 17:56 ` Random832 2017-09-19 18:31 ` Steffen Nurpmeso @ 2017-09-19 19:31 ` Lawrence Stewart 2017-09-20 3:13 ` Larry McVoy 2 siblings, 0 replies; 204+ messages in thread From: Lawrence Stewart @ 2017-09-19 19:31 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1172 bytes --] Being too lazy to type __FILE__ and __LINE__ all the time I tend to do this: #define whereprintf(fmt, ...) printf("%s:%d: " fmt, __FILE__, __LINE__, ##__VA_ARGS__) which works when fmt is a constant anyway. My rant about error messages is that programmers too infrequently make them actionable. I group errors into 4 categories: * Things the user can fix (file not found) * Temporary resource constraints (destination unreachable, disk full) * Things the admin can fix (library not found) * Things the author of the program can fix (assertion failures) In each case, the kind of information needed is different, and the level of noise and specificity may differ as well. The user wants to know (a) how to fix it or (b) who to ask. Finally, When faced with an unfamiliar error, the natural reaction of a 2017 user is to cut and past the error into a search engine. Consequently I think often the right thing to do is to put a unique ID in the error message that will find it on the support website (or user forum, or …) -L PS Daughter is working on a master’s project to improve the quality of errors from the python interpreter/compiler. Sorely needed. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-19 17:56 ` Random832 2017-09-19 18:31 ` Steffen Nurpmeso 2017-09-19 19:31 ` Lawrence Stewart @ 2017-09-20 3:13 ` Larry McVoy 2017-09-23 22:24 ` Ralph Corderoy 2 siblings, 1 reply; 204+ messages in thread From: Larry McVoy @ 2017-09-20 3:13 UTC (permalink / raw) On Tue, Sep 19, 2017 at 01:56:48PM -0400, Random832 wrote: > On Tue, Sep 19, 2017, at 09:56, Larry McVoy wrote: > > On Tue, Sep 19, 2017 at 03:53:59PM +0200, Steffen Nurpmeso wrote: > > > |void > > > |my_perror(char *file, int line, char *msg) > > > |{ > > > | char *p = 0; > > > | int save = errno; > > > | > > > | if (p = getenv("_BK_VERSION")) { > > > | if (strneq(p, "bk-", 3)) p += 3; > > > | fprintf(stderr, "%s:%d (%s): ", file, line, p); > > > |} else { > > > | fprintf(stderr, "%s:%d: ", file, line); > > > |} > > > | if (p = strerror(errno)) { > > > | fprintf(stderr, "%s: %s\n", msg, p); > > > |} else { > > > | fprintf(stderr, "%s: errno=%d\n", msg, errno); > > > |} > > > | errno = save; > > > |} > > > | > > > |libc should do that. > > > > > > That really made me wonder why "save" is not used, errno may > > > eventually change along the way. Ok ok, but.. well. > > > > Huh? save is set with errno and then errno is restored to save. The > > point of save is to do the library calls (which do syscalls which > > could in theory change errno) and leave it the same as it was on > > the way in. > > I think his point was that you should be passing save (rather than > errno) to the strerror and the last printf, because the preceding > library calls may have changed errno. Thanks for that insight. That code has been working for decades but I think the reason it works is if it works then errno doesn't change and if it doesn't work then we're not going to see the output. So passing save is technically correct but not sure it is practically correct. Anyone have an opinion? ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-20 3:13 ` Larry McVoy @ 2017-09-23 22:24 ` Ralph Corderoy 0 siblings, 0 replies; 204+ messages in thread From: Ralph Corderoy @ 2017-09-23 22:24 UTC (permalink / raw) Hi Larry, > > > > > void > > > > > my_perror(char *file, int line, char *msg) > > > > > { > > > > > char *p = 0; > > > > > int save = errno; > > > > > > > > > > if (p = getenv("_BK_VERSION")) { > > > > > if (strneq(p, "bk-", 3)) p += 3; > > > > > fprintf(stderr, "%s:%d (%s): ", file, line, p); > > > > > } else { > > > > > fprintf(stderr, "%s:%d: ", file, line); > > > > > } > > > > > if (p = strerror(errno)) { > > > > > fprintf(stderr, "%s: %s\n", msg, p); > > > > > } else { > > > > > fprintf(stderr, "%s: errno=%d\n", msg, errno); > > > > > } > > > > > errno = save; > > > > > } > > I think the reason it works is if it works then errno doesn't change > and if it doesn't work then we're not going to see the output. Unless the failure under fprintf(3) is transient? > So passing save is technically correct but not sure it is practically > correct. Passing `save' would also stop readers wondering why it's not being passed. :-) Also, `p = strerror(errno)' is always going to be true; strerror(3) doesn't return NULL. To check for strerror() errors one must errno=0 and then check errno afterwards; strerror() can kick off LC_MESSAGES stuff so errors are possible. Yes, how does one then report that error... Another option when in dire straits, e.g. about to _exit() and trying hard to get *something* to FD 2, is to writev(2) since the iov[] will be a fixed size and the only formatting issue in the above code is the `%d' and the space needed by its sprintf(3) can be found at compile time. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-19 2:50 ` Larry McVoy ` (2 preceding siblings ...) 2017-09-19 13:53 ` Steffen Nurpmeso @ 2017-09-19 14:32 ` Clem Cole 2017-09-19 14:42 ` Larry McVoy 3 siblings, 1 reply; 204+ messages in thread From: Clem Cole @ 2017-09-19 14:32 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1316 bytes --] On Mon, Sep 18, 2017 at 10:50 PM, Larry McVoy <lm at mcvoy.com> wrote: > So in the BitKeeper source, perror is redifined to my_perror which is > this: > > void > my_perror(char *file, int line, char *msg) > { > char *p = 0; > int save = errno; > > if (p = getenv("_BK_VERSION")) { > if (strneq(p, "bk-", 3)) p += 3; > fprintf(stderr, "%s:%d (%s): ", file, line, p); > } else { > fprintf(stderr, "%s:%d: ", file, line); > } > if (p = strerror(errno)) { > fprintf(stderr, "%s: %s\n", msg, p); > } else { > fprintf(stderr, "%s: errno=%d\n", msg, errno); > } > errno = save; > } > > libc should do that. +1, indeed! - knowing where the the error came from (file and line) is huge. Yeah it means putting it in the preprocessor, which has some issues; but it comes back to a previous comment I have made -- I really believe a serious production language needs a preprocessor that is carefully used because there are places (like this one) that just makes the right things happen. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170919/32420dee/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-19 14:32 ` Clem Cole @ 2017-09-19 14:42 ` Larry McVoy 2017-09-19 15:12 ` Clem Cole 2017-09-19 18:03 ` Random832 0 siblings, 2 replies; 204+ messages in thread From: Larry McVoy @ 2017-09-19 14:42 UTC (permalink / raw) On Tue, Sep 19, 2017 at 10:32:20AM -0400, Clem Cole wrote: > On Mon, Sep 18, 2017 at 10:50 PM, Larry McVoy <lm at mcvoy.com> wrote: > > > So in the BitKeeper source, perror is redifined to my_perror which is > > this: > > > > void > > my_perror(char *file, int line, char *msg) > > { > > char *p = 0; > > int save = errno; > > > > if (p = getenv("_BK_VERSION")) { > > if (strneq(p, "bk-", 3)) p += 3; > > fprintf(stderr, "%s:%d (%s): ", file, line, p); > > } else { > > fprintf(stderr, "%s:%d: ", file, line); > > } > > if (p = strerror(errno)) { > > fprintf(stderr, "%s: %s\n", msg, p); > > } else { > > fprintf(stderr, "%s: errno=%d\n", msg, errno); > > } > > errno = save; > > } > > > > libc should do that. > > > ???+1, indeed!??? - knowing where the the error came from (file and line) is > huge. Yeah it means putting it in the preprocessor, which has some issues; > but it comes back to a previous comment I have made -- I really believe a > serious production language needs a preprocessor that is carefully used > because there are places (like this one) that just makes the right things > happen. Yep. And the _BK_VERSION stuff is obviously BK specific, but if there was a way to generalize that so you could have _APPLICATION_VERSION or something and that got printed with the error then you get stuff like slib.c:1653 (bk-7.3): open failed: permission denied which is way way way more useful than just permission denied. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-19 14:42 ` Larry McVoy @ 2017-09-19 15:12 ` Clem Cole 2017-09-19 18:03 ` Random832 1 sibling, 0 replies; 204+ messages in thread From: Clem Cole @ 2017-09-19 15:12 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 511 bytes --] On Tue, Sep 19, 2017 at 10:42 AM, Larry McVoy <lm at mcvoy.com> wrote: > slib.c:1653 (bk-7.3): open failed: permission denied > > which is way way way more useful than just permission denied. And just as easy to use for the programmer... which is why it make so much sense. This is an example of what I mean by "good taste." -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170919/d2bf1514/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-19 14:42 ` Larry McVoy 2017-09-19 15:12 ` Clem Cole @ 2017-09-19 18:03 ` Random832 1 sibling, 0 replies; 204+ messages in thread From: Random832 @ 2017-09-19 18:03 UTC (permalink / raw) On Tue, Sep 19, 2017, at 10:42, Larry McVoy wrote: > slib.c:1653 (bk-7.3): open failed: permission denied > > which is way way way more useful than just permission denied. Well. It's less useful in one way - it doesn't say what file it was trying to open. You could pass the filename *instead* of "open failed", but that still omits the issue I had pointed out: what were you trying to open the file for (at the very least, were you trying to read, write, or exec it). Ideally the function would have a format and arguments. Another thing that's unfortunately not easy to solve is whether an error accessing a file was due to a problem (permissions/nonexistence) with the file itself, or one of the directories along the way. This information isn't provided by the OS, either, so at best you can detect an error and then check every component yourself. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-08 20:54 [TUHS] Happy birthday, Dennis Ritchie! Dave Horsfall ` (2 preceding siblings ...) 2017-09-08 21:14 ` William Pechter @ 2017-09-10 9:44 ` arnold 2017-09-13 23:22 ` Dave Horsfall 3 siblings, 1 reply; 204+ messages in thread From: arnold @ 2017-09-10 9:44 UTC (permalink / raw) Dave Horsfall <dave at horsfall.org> wrote: > Sadly no longer with us (he exited in 2011), he was forked in 1941. Just > think, if it wasn't for him and Ken, we'd all be running Windoze, and > thinking it's wonderful. > > A Unix bigot through and through, I remain, > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." I just want to say that Dennis Ritchie was "a scholar and a gentleman". He was always warm, polite, friendly, and down to earth, both in his correspondance with me, and in direct conversation the few times I talked to him in person at USENIX conferences. He helped out A LOT when I had Unix history questions for whatever books I happened to be writing. Not only to me, of course, but he was that way with everyone. He also had a warm sense of humor, and was very active in the TUHS and Unix history preservation. He continues to be missed. Arnold ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-10 9:44 ` [TUHS] Happy birthday, Dennis Ritchie! arnold @ 2017-09-13 23:22 ` Dave Horsfall 2017-09-14 16:11 ` Ian Zimmerman 0 siblings, 1 reply; 204+ messages in thread From: Dave Horsfall @ 2017-09-13 23:22 UTC (permalink / raw) On Sun, 10 Sep 2017, arnold at skeeve.com wrote: > I just want to say that Dennis Ritchie was "a scholar and a gentleman". > He was always warm, polite, friendly, and down to earth, both in his > correspondance with me, and in direct conversation the few times I > talked to him in person at USENIX conferences. He helped out A LOT when > I had Unix history questions for whatever books I happened to be > writing. He was at an AUUG conference in Sydney, and although I never got to shake hands with him (he had too many fans around him, and I had a home and a wife to go back to, not to mention two cats), he struck me as being the perfect gentleman. Mr. and Mrs. Ritchie, you raised a damned good son... > Not only to me, of course, but he was that way with everyone. He also > had a warm sense of humor, and was very active in the TUHS and Unix > history preservation. Agreed. > He continues to be missed. And I just wish that the Penguin/OS community would realise this; if you believe those silly sods, you'd think that they invented Unix... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-13 23:22 ` Dave Horsfall @ 2017-09-14 16:11 ` Ian Zimmerman 2017-09-14 16:15 ` Steve Nickolas 0 siblings, 1 reply; 204+ messages in thread From: Ian Zimmerman @ 2017-09-14 16:11 UTC (permalink / raw) On 2017-09-14 09:22, Dave Horsfall wrote: > > He continues to be missed. > > And I just wish that the Penguin/OS community would realise this; if > you believe those silly sods, you'd think that they invented Unix... Maybe some are deluded like that. But the more typical case (and I saw this personally not just on "the Internet") are those who actively and consciously disdain Unix, and want Penguin kernel based systems to move to a completely new and different userland, free from any links to Unix history. And we should stop assuming they're kidding when they say so openly. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. Do obvious transformation on domain to reply privately _only_ on Usenet. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-14 16:11 ` Ian Zimmerman @ 2017-09-14 16:15 ` Steve Nickolas 2017-09-14 19:30 ` Theodore Ts'o 2017-09-14 19:39 ` Kurt H Maier 0 siblings, 2 replies; 204+ messages in thread From: Steve Nickolas @ 2017-09-14 16:15 UTC (permalink / raw) On Thu, 14 Sep 2017, Ian Zimmerman wrote: > On 2017-09-14 09:22, Dave Horsfall wrote: > >>> He continues to be missed. >> >> And I just wish that the Penguin/OS community would realise this; if >> you believe those silly sods, you'd think that they invented Unix... > > Maybe some are deluded like that. But the more typical case (and I saw > this personally not just on "the Internet") are those who actively and > consciously disdain Unix, and want Penguin kernel based systems to move > to a completely new and different userland, free from any links to Unix > history. > > And we should stop assuming they're kidding when they say so openly. > > Isn't that pretty much just Lennart Poettering and his fan club? -uso. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-14 16:15 ` Steve Nickolas @ 2017-09-14 19:30 ` Theodore Ts'o 2017-09-14 19:52 ` Steve Nickolas 2017-09-14 19:39 ` Kurt H Maier 1 sibling, 1 reply; 204+ messages in thread From: Theodore Ts'o @ 2017-09-14 19:30 UTC (permalink / raw) On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote: > > Maybe some are deluded like that. But the more typical case (and I saw > > this personally not just on "the Internet") are those who actively and > > consciously disdain Unix, and want Penguin kernel based systems to move > > to a completely new and different userland, free from any links to Unix > > history. > > > > And we should stop assuming they're kidding when they say so openly. > > > > Isn't that pretty much just Lennart Poettering and his fan club? It's mostly Lennart Poettering and his fan club, but it's also important to remember that Unix was not perfect. For years, I've been ranting about the telldir/seekdir interface, for which JFS has three b-trees that have to be updated for every directory operation --- one of which was added *just* because of telldir/seekdir. Other file systems make other design choices or go through other bits of hell just because of telldir/seekdir, but assuming a 32-bit cookie which must survive potentially indefinitely, with the readdir "will return file names exactly zero or one times" guarantees required by POSIX, is rather hellish. Or, say the atime update requirement, which can be a performance killer, and for which the default on Linux violates Posix, and so I suppose it technically isn't allowed to use the Unix trademark anyway. I'm sure the Plan 9 folks could come up with other Unix shortcomings. :-) - Ted ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-14 19:30 ` Theodore Ts'o @ 2017-09-14 19:52 ` Steve Nickolas 2017-09-14 22:03 ` Christian Groessler 0 siblings, 1 reply; 204+ messages in thread From: Steve Nickolas @ 2017-09-14 19:52 UTC (permalink / raw) On Thu, 14 Sep 2017, Theodore Ts'o wrote: > On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote: >>> Maybe some are deluded like that. But the more typical case (and I saw >>> this personally not just on "the Internet") are those who actively and >>> consciously disdain Unix, and want Penguin kernel based systems to move >>> to a completely new and different userland, free from any links to Unix >>> history. >>> >>> And we should stop assuming they're kidding when they say so openly. >>> >> >> Isn't that pretty much just Lennart Poettering and his fan club? > > It's mostly Lennart Poettering and his fan club, but it's also > important to remember that Unix was not perfect. > > For years, I've been ranting about the telldir/seekdir interface, for > which JFS has three b-trees that have to be updated for every > directory operation --- one of which was added *just* because of > telldir/seekdir. Other file systems make other design choices or go > through other bits of hell just because of telldir/seekdir, but > assuming a 32-bit cookie which must survive potentially indefinitely, > with the readdir "will return file names exactly zero or one times" > guarantees required by POSIX, is rather hellish. > > Or, say the atime update requirement, which can be a performance > killer, and for which the default on Linux violates Posix, and so I > suppose it technically isn't allowed to use the Unix trademark anyway. > > I'm sure the Plan 9 folks could come up with other Unix shortcomings. :-) > > - Ted > I never managed to pull it off, but I tried creating a full live Linux environment based on musl, clang, Heirloom Toolchest and OpenBSD/NetBSD sources. The idea was that I wanted to make a "Real Unix" that happened to have Linux as its kernel. (It also would have run the CDE as its default desktop.) One thing I did come up with was, if I were to pull it off, it would be a Linux distribution that rightfully could NOT be called, by any means, "GNU/Linux" - and some heads would explode. (I still want to do it, but I remain at a loss as to execution.) -uso. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-14 19:52 ` Steve Nickolas @ 2017-09-14 22:03 ` Christian Groessler 2017-09-14 22:39 ` Erik Berls 0 siblings, 1 reply; 204+ messages in thread From: Christian Groessler @ 2017-09-14 22:03 UTC (permalink / raw) On 09/14/17 21:52, Steve Nickolas wrote: > I never managed to pull it off, but I tried creating a full live Linux > environment based on musl, clang, Heirloom Toolchest and > OpenBSD/NetBSD sources. The idea was that I wanted to make a "Real > Unix" that happened to have Linux as its kernel. (It also would have > run the CDE as its default desktop.) I, too, was toying with the idea of creating a NetBSD distribution which uses the Linux kernel and NetBSD userland. I very much like the concept of going to /usr/src and typing "make build" (or "make world" on FreeBSD) and have the whole base system rebuilt. I've played with Gentoo Linux which also builds from source, but I found it too complicated (for me, at least). On the BSDs it's just Makefiles, and no strange python (or whatever) scripts to build the system. Maybe when I'm retired and have plenty of time... regards, chris ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-14 22:03 ` Christian Groessler @ 2017-09-14 22:39 ` Erik Berls 2017-09-14 22:52 ` ron minnich 0 siblings, 1 reply; 204+ messages in thread From: Erik Berls @ 2017-09-14 22:39 UTC (permalink / raw) No, I am Spartacus! I've toyed with this idea as well, mostly for getting a NetBSD environment in a Docker container. Maybe we should pool resources? On Thu, Sep 14, 2017 at 15:04 Christian Groessler <chris at groessler.org> wrote: > On 09/14/17 21:52, Steve Nickolas wrote: > > > I never managed to pull it off, but I tried creating a full live Linux > > environment based on musl, clang, Heirloom Toolchest and > > OpenBSD/NetBSD sources. The idea was that I wanted to make a "Real > > Unix" that happened to have Linux as its kernel. (It also would have > > run the CDE as its default desktop.) > > > I, too, was toying with the idea of creating a NetBSD distribution which > uses the Linux kernel and NetBSD userland. > I very much like the concept of going to /usr/src and typing "make > build" (or "make world" on FreeBSD) and have the > whole base system rebuilt. > > I've played with Gentoo Linux which also builds from source, but I found > it too complicated (for me, at least). On the > BSDs it's just Makefiles, and no strange python (or whatever) scripts to > build the system. > > Maybe when I'm retired and have plenty of time... > > regards, > chris > > -- -=erik. -- Look, I lived through the Gray Davis years. I *need* a UPS. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/bb82f173/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-14 22:39 ` Erik Berls @ 2017-09-14 22:52 ` ron minnich 2017-09-14 23:04 ` Warner Losh 2017-09-14 23:06 ` Bakul Shah 0 siblings, 2 replies; 204+ messages in thread From: ron minnich @ 2017-09-14 22:52 UTC (permalink / raw) The u-root project (u-root.tk) is aimed at creating the *nix tools in Go. The targets are firmware where linux and an initramfs are loaded; and root file systems. One goal was to get back to old school unix where the root always included the source to create the commands. In the non-firmware mode all the sources are there and they are compiled on demand, save for the 4 go tooclhain binaries and /init. It takes about 15 seconds to compile all the tools at present. We've got a demo OS for Chromebooks based on u-root called NiChrome (NiChrome is an alloy of Chrome). This was a summer project for 2 interns here. It helped show that the idea can work to support an OS distro. We've also shown that linux and a u-root initramfs can replace most of UEFI firmware on the Open Compute Platform nodes, reducing boot time from 8 minutes to 17 seconds. Not as fast as the 3 seconds I'd like but you gotta start somewhere, and most of that time is beyond our control. We can always use help if you're interested. I'm ok with C for kernels but don't want to use it again in user mode, hence this project. ron On Thu, Sep 14, 2017 at 3:39 PM Erik Berls <erik at ono-sendai.com> wrote: > No, I am Spartacus! > > I've toyed with this idea as well, mostly for getting a NetBSD environment > in a Docker container. > > Maybe we should pool resources? > > On Thu, Sep 14, 2017 at 15:04 Christian Groessler <chris at groessler.org> > wrote: > >> On 09/14/17 21:52, Steve Nickolas wrote: >> >> > I never managed to pull it off, but I tried creating a full live Linux >> > environment based on musl, clang, Heirloom Toolchest and >> > OpenBSD/NetBSD sources. The idea was that I wanted to make a "Real >> > Unix" that happened to have Linux as its kernel. (It also would have >> > run the CDE as its default desktop.) >> >> >> I, too, was toying with the idea of creating a NetBSD distribution which >> uses the Linux kernel and NetBSD userland. >> I very much like the concept of going to /usr/src and typing "make >> build" (or "make world" on FreeBSD) and have the >> whole base system rebuilt. >> >> I've played with Gentoo Linux which also builds from source, but I found >> it too complicated (for me, at least). On the >> BSDs it's just Makefiles, and no strange python (or whatever) scripts to >> build the system. >> >> Maybe when I'm retired and have plenty of time... >> >> regards, >> chris >> >> -- > -=erik. > -- > Look, I lived through the Gray Davis years. I *need* a UPS. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/3e14649e/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-14 22:52 ` ron minnich @ 2017-09-14 23:04 ` Warner Losh 2017-09-14 23:14 ` Bakul Shah 2017-09-15 19:01 ` Chris Torek 2017-09-14 23:06 ` Bakul Shah 1 sibling, 2 replies; 204+ messages in thread From: Warner Losh @ 2017-09-14 23:04 UTC (permalink / raw) First off, this sounds cool! One nit pick though... On Thu, Sep 14, 2017 at 4:52 PM, ron minnich <rminnich at gmail.com> wrote: > It takes about 15 seconds to compile all the tools at present. > If you want to replicate the old-school Unix experience, you'd need it to take more like 15 hours to compile all the tools :) My DEC Rainbow running Venix (v7 port) takes about 15 hours to build the bits of the v7 tree that build on it. I don't have the sources to Venix, but a long-term project is to recreate them using the compiler supplied and comparison to the binaries shipped... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/cbc9fa90/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-14 23:04 ` Warner Losh @ 2017-09-14 23:14 ` Bakul Shah 2017-09-15 19:01 ` Chris Torek 1 sibling, 0 replies; 204+ messages in thread From: Bakul Shah @ 2017-09-14 23:14 UTC (permalink / raw) > On Sep 14, 2017, at 4:04 PM, Warner Losh <imp at bsdimp.com> wrote: > > First off, this sounds cool! One nit pick though... > > On Thu, Sep 14, 2017 at 4:52 PM, ron minnich <rminnich at gmail.com> wrote: > It takes about 15 seconds to compile all the tools at present. > > If you want to replicate the old-school Unix experience, you'd need it to take more like 15 hours to compile all the tools :) > > My DEC Rainbow running Venix (v7 port) takes about 15 hours to build the bits of the v7 tree that build on it. I don't have the sources to Venix, but a long-term project is to recreate them using the compiler supplied and comparison to the binaries shipped... You can do better than your old-school Unix experience with a pi and linux :-) On the 1st gen RasPi the linux kernel took 10+ hours to build from scratch. In contrast the plan9 kernel took one minute. The equivalent of FreeBSD's "make world" for plan9 took 4 minutes. IIRC half of it was for ghostscript. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-14 23:04 ` Warner Losh 2017-09-14 23:14 ` Bakul Shah @ 2017-09-15 19:01 ` Chris Torek 2017-09-15 19:50 ` Lyndon Nerenberg 1 sibling, 1 reply; 204+ messages in thread From: Chris Torek @ 2017-09-15 19:01 UTC (permalink / raw) >My DEC Rainbow running Venix (v7 port) takes about 15 hours to build the >bits of the v7 tree that build on it. In the spirit of complaining about compile times :-) ... I like to build my freebsd ports tree from source. Every time webkit2 needs an update, my box (which I admit is no longer super-fast, but is not exactly slow either) takes well over three hours to grind through it, using all eight cores. (I never timed it, I always just left it to its own devices after a while.) Much of this can be blamed on the complexity of compiling C++ in general (the "best type" matching rules are not simple). Chris ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-15 19:01 ` Chris Torek @ 2017-09-15 19:50 ` Lyndon Nerenberg 2017-09-15 19:56 ` ron minnich 2017-09-15 20:34 ` Chris Torek 0 siblings, 2 replies; 204+ messages in thread From: Lyndon Nerenberg @ 2017-09-15 19:50 UTC (permalink / raw) > In the spirit of complaining about compile times :-) ... I like to > build my freebsd ports tree from source. Every time webkit2 needs > an update, my box (which I admit is no longer super-fast, but is > not exactly slow either) takes well over three hours to grind > through it, using all eight cores. (I never timed it, I always > just left it to its own devices after a while.) Forget ports! /usr/src is bad enough. Running buildworld, it takes longer to build the flippin' compilers (llvm) than it does to build the entire rest of the OS. This is not progress. --lyndon ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-15 19:50 ` Lyndon Nerenberg @ 2017-09-15 19:56 ` ron minnich 2017-09-15 20:34 ` Chris Torek 1 sibling, 0 replies; 204+ messages in thread From: ron minnich @ 2017-09-15 19:56 UTC (permalink / raw) huh. Time to build all of plan 9 -- libraries, commands, windowing system, all kernels -- was always a few minutes. It was really annoying -- people just assumed there was not much capability there because it took less time to build than to run an autoconf on GNU tools :-) I wonder what Ken was doing wrong? (fwiw, the Ken C compilers were a wonder -- they did not link against the C library, they just made the system calls directly, malloc was defined to brk(), and there was no free() -- and the code is tiny) It's nice to see the kenc spirit still alive in the Go toolchain -- although that makes sense, since the up through 1.4 or so the go toolchain was derived from ken c :-) ron On Fri, Sep 15, 2017 at 12:50 PM Lyndon Nerenberg <lyndon at orthanc.ca> wrote: > > In the spirit of complaining about compile times :-) ... I like to > > build my freebsd ports tree from source. Every time webkit2 needs > > an update, my box (which I admit is no longer super-fast, but is > > not exactly slow either) takes well over three hours to grind > > through it, using all eight cores. (I never timed it, I always > > just left it to its own devices after a while.) > > Forget ports! /usr/src is bad enough. Running buildworld, it takes > longer to build the flippin' compilers (llvm) than it does to build the > entire rest of the OS. This is not progress. > > --lyndon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170915/76ca31b7/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-15 19:50 ` Lyndon Nerenberg 2017-09-15 19:56 ` ron minnich @ 2017-09-15 20:34 ` Chris Torek 1 sibling, 0 replies; 204+ messages in thread From: Chris Torek @ 2017-09-15 20:34 UTC (permalink / raw) >Forget ports! /usr/src is bad enough. Running buildworld, it takes >longer to build the flippin' compilers (llvm) than it does to build the >entire rest of the OS. This is not progress. Common thread: LLVM is written in C++. (Also, at some point during compilation, at least some versions grow quite big, using 20 GB of RAM or whatever. And C++ is hard on the linkers as well...) Chris ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-14 22:52 ` ron minnich 2017-09-14 23:04 ` Warner Losh @ 2017-09-14 23:06 ` Bakul Shah 2017-09-15 0:47 ` ron minnich 1 sibling, 1 reply; 204+ messages in thread From: Bakul Shah @ 2017-09-14 23:06 UTC (permalink / raw) > On Sep 14, 2017, at 3:52 PM, ron minnich <rminnich at gmail.com> wrote: > > The u-root project (u-root.tk) is aimed at creating the *nix tools in Go. The targets are firmware where linux and an initramfs are loaded; and root file systems. > > One goal was to get back to old school unix where the root always included the source to create the commands. In the non-firmware mode all the sources are there > and they are compiled on demand, save for the 4 go tooclhain binaries and /init. > > It takes about 15 seconds to compile all the tools at present. > > We've got a demo OS for Chromebooks based on u-root called NiChrome (NiChrome is an alloy of Chrome). This was a summer project for 2 interns here. It helped show that the idea can work to support an OS distro. > > We've also shown that linux and a u-root initramfs can replace most of UEFI firmware on the Open Compute Platform nodes, reducing boot time from 8 minutes to 17 seconds. Not as fast as the 3 seconds I'd like but you gotta start somewhere, and most of that time is beyond our control. > > We can always use help if you're interested. I'm ok with C for kernels but don't want to use it again in user mode, hence this Nice! How hard would it be to replace linux with FreeBSD or plan9? I guess linux->plan9 is progressively less and less h/w support more and more fun to hack on the kernel! ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-14 23:06 ` Bakul Shah @ 2017-09-15 0:47 ` ron minnich 0 siblings, 0 replies; 204+ messages in thread From: ron minnich @ 2017-09-15 0:47 UTC (permalink / raw) On Thu, Sep 14, 2017 at 4:06 PM Bakul Shah <bakul at bitblocks.com> wrote: > > > How hard would it be to replace linux with FreeBSD or plan9? > I guess linux->plan9 is progressively less and less h/w > support more and more fun to hack on the kernel! whatever go runs on, u-root will run on, but there are places we had to use Linux-specific stuff (e.g. netlink) that you'd have to write code for or you won't get thinks like the ip command or dhcp client, and so on. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170915/6eeb3561/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-14 16:15 ` Steve Nickolas 2017-09-14 19:30 ` Theodore Ts'o @ 2017-09-14 19:39 ` Kurt H Maier 2017-09-14 20:09 ` [TUHS] Happy birthday, Dennis Ritchie! [ really Pottering vs UNIX ] Jon Steinhart 2017-09-14 21:35 ` [TUHS] Happy birthday, Dennis Ritchie! Theodore Ts'o 1 sibling, 2 replies; 204+ messages in thread From: Kurt H Maier @ 2017-09-14 19:39 UTC (permalink / raw) On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote: > > Isn't that pretty much just Lennart Poettering and his fan club? > It's right there in the name "GNU" as well. There's a whole generation of computer people out here for whom bash and gawk are fossilized in their substrata, and they get mad when someone suggests maybe other tools exist. khm ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really Pottering vs UNIX ] 2017-09-14 19:39 ` Kurt H Maier @ 2017-09-14 20:09 ` Jon Steinhart 2017-09-14 21:35 ` [TUHS] Happy birthday, Dennis Ritchie! Theodore Ts'o 1 sibling, 0 replies; 204+ messages in thread From: Jon Steinhart @ 2017-09-14 20:09 UTC (permalink / raw) Kurt H Maier writes: > On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote: > > > > Isn't that pretty much just Lennart Poettering and his fan club? > > > > It's right there in the name "GNU" as well. There's a whole generation > of computer people out here for whom bash and gawk are fossilized in > their substrata, and they get mad when someone suggests maybe other > tools exist. > > khm Well, I'd suggest that a lot of this has to do with people who have vision and people who don't. When you look at UNIX, you see something created by a bunch of very talented people who had a reasonably shared vision of what they were trying to achieve. I happen to be good friends with John Gilmore, and early Sun employee and one of the founders of Cygnus Solutions which one can argue did more for the acceptance of open source than anything else. Whenever we get into an argument (which is really easy to do with John) over how to do something he falls back onto "When I was a Cygnus and wrote GNU tar..." I always point out that implementing something that was already defined was way easier than defining something new, and a completely different skill set. So I would make the claim that Pottering et. al. are not good definers, and their model for definition comes from Microsoft which is also not a good definer. Along these lines, I think that the demise of UNIX began with AT&T/USL for the reasons above. I would much rather use UNIX Version III than UNIX System III. Jon ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-14 19:39 ` Kurt H Maier 2017-09-14 20:09 ` [TUHS] Happy birthday, Dennis Ritchie! [ really Pottering vs UNIX ] Jon Steinhart @ 2017-09-14 21:35 ` Theodore Ts'o 2017-09-15 1:40 ` Ron Natalie 2017-09-16 3:40 ` Larry McVoy 1 sibling, 2 replies; 204+ messages in thread From: Theodore Ts'o @ 2017-09-14 21:35 UTC (permalink / raw) On Thu, Sep 14, 2017 at 12:39:05PM -0700, Kurt H Maier wrote: > On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote: > > > > Isn't that pretty much just Lennart Poettering and his fan club? > > > > It's right there in the name "GNU" as well. There's a whole generation > of computer people out here for whom bash and gawk are fossilized in > their substrata, and they get mad when someone suggests maybe other > tools exist. The use of "GNU" as in "GNU/Linux" is something that was pushed by Stallman and the Free Software Foundation, and actively abosed, or mostly ignored by the majority of the Linux community. See [1] if you want more details on that whole mess. Of the distributions, I believe only Debian has adopted the use of GNU/Linux in their official documentation, but it's not used by most Debian users or developers from my experience. I'll also note that Debian has pushed to use /bin/dash, as their default /bin/sh, and not /bin/bash, to try to make Debian's shell scripts to be more portable. (And for speed reasons, since dash is faster than bash). [1] https://en.wikipedia.org/wiki/GNU/Linux_naming_controversy - Ted ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-14 21:35 ` [TUHS] Happy birthday, Dennis Ritchie! Theodore Ts'o @ 2017-09-15 1:40 ` Ron Natalie 2017-09-15 14:04 ` Larry McVoy 2017-09-16 3:40 ` Larry McVoy 1 sibling, 1 reply; 204+ messages in thread From: Ron Natalie @ 2017-09-15 1:40 UTC (permalink / raw) Frankly, I don't give a hoot about what the FSF or especially RMS cares about. RMS used to show up at my house on a regular basis, and I spent time in the early FSF with some of the people I really respected other than RMS (like Len Tower). RMS while condemning everybody else, cares little about other than himself and his sociopathically depraved views of the way the world should be. And as Forrest Gump would say "Tha'ts all I have to say about that." ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-15 1:40 ` Ron Natalie @ 2017-09-15 14:04 ` Larry McVoy 0 siblings, 0 replies; 204+ messages in thread From: Larry McVoy @ 2017-09-15 14:04 UTC (permalink / raw) On Thu, Sep 14, 2017 at 09:40:27PM -0400, Ron Natalie wrote: > > Frankly, I don't give a hoot about what the FSF or especially RMS cares > about. RMS used to show up at my house on a regular basis, and I spent > time in the early FSF with some of the people I really respected other than > RMS (like Len Tower). RMS while condemning everybody else, cares little > about other than himself and his sociopathically depraved views of the way > the world should be. And as Forrest Gump would say "Tha'ts all I have to > say about that." Amen. Not a fan. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-14 21:35 ` [TUHS] Happy birthday, Dennis Ritchie! Theodore Ts'o 2017-09-15 1:40 ` Ron Natalie @ 2017-09-16 3:40 ` Larry McVoy 2017-09-16 7:45 ` Steve Nickolas ` (3 more replies) 1 sibling, 4 replies; 204+ messages in thread From: Larry McVoy @ 2017-09-16 3:40 UTC (permalink / raw) On Thu, Sep 14, 2017 at 05:35:35PM -0400, Theodore Ts'o wrote: > On Thu, Sep 14, 2017 at 12:39:05PM -0700, Kurt H Maier wrote: > > On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote: > > > > > > Isn't that pretty much just Lennart Poettering and his fan club? > > > > > > > It's right there in the name "GNU" as well. There's a whole generation > > of computer people out here for whom bash and gawk are fossilized in > > their substrata, and they get mad when someone suggests maybe other > > tools exist. > > The use of "GNU" as in "GNU/Linux" is something that was pushed by > Stallman and the Free Software Foundation, and actively abosed, or > mostly ignored by the majority of the Linux community. As well it should be. My colors are showing here, but I'm really sick of the FSF slapping their name on other people's work. If Stallman wants it to be called GNU/Linux let him write a kernel. He didn't, he can't, yet he wants credit. I got pretty disgusted back in the day when everything that was GPLed suddenly became a GNU project. The GNU guys have written very, very little code. They are all about the license, which is fine, but I get off the bus when they are claiming credit for work they did not do. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-16 3:40 ` Larry McVoy @ 2017-09-16 7:45 ` Steve Nickolas 2017-09-16 12:59 ` Ron Natalie ` (2 subsequent siblings) 3 siblings, 0 replies; 204+ messages in thread From: Steve Nickolas @ 2017-09-16 7:45 UTC (permalink / raw) On Fri, 15 Sep 2017, Larry McVoy wrote: > On Thu, Sep 14, 2017 at 05:35:35PM -0400, Theodore Ts'o wrote: >> On Thu, Sep 14, 2017 at 12:39:05PM -0700, Kurt H Maier wrote: >>> On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote: >>>> >>>> Isn't that pretty much just Lennart Poettering and his fan club? >>>> >>> >>> It's right there in the name "GNU" as well. There's a whole generation >>> of computer people out here for whom bash and gawk are fossilized in >>> their substrata, and they get mad when someone suggests maybe other >>> tools exist. >> >> The use of "GNU" as in "GNU/Linux" is something that was pushed by >> Stallman and the Free Software Foundation, and actively abosed, or >> mostly ignored by the majority of the Linux community. > > As well it should be. My colors are showing here, but I'm really sick > of the FSF slapping their name on other people's work. If Stallman > wants it to be called GNU/Linux let him write a kernel. He didn't, > he can't, yet he wants credit. I got pretty disgusted back in the day > when everything that was GPLed suddenly became a GNU project. The GNU > guys have written very, very little code. > > They are all about the license, which is fine, but I get off the bus > when they are claiming credit for work they did not do. > The GNU Project has a kernel, The HURD, but iirc, it's still as unusable now as it has been for decades. Which is why Linux wound up being the de-facto kernel of the GNU system, even while The HURD is still their official kernel. -uso. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-16 3:40 ` Larry McVoy 2017-09-16 7:45 ` Steve Nickolas @ 2017-09-16 12:59 ` Ron Natalie 2017-09-16 18:19 ` Andy Kosela 2017-09-17 18:37 ` Chet Ramey 2017-09-16 19:20 ` arnold 2017-09-17 18:25 ` Chet Ramey 3 siblings, 2 replies; 204+ messages in thread From: Ron Natalie @ 2017-09-16 12:59 UTC (permalink / raw) RMS hates UNIX. That was clear in the original manifesto. But he's also a megalomaniac and believes that if you even use a GNU tool your work becomes his. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-16 12:59 ` Ron Natalie @ 2017-09-16 18:19 ` Andy Kosela 2017-09-17 18:37 ` Chet Ramey 1 sibling, 0 replies; 204+ messages in thread From: Andy Kosela @ 2017-09-16 18:19 UTC (permalink / raw) On Saturday, September 16, 2017, Ron Natalie <ron at ronnatalie.com> wrote: > RMS hates UNIX. That was clear in the original manifesto. There can be some truth in it -- after all he came from MIT, which was anti-unix as much as you can get. When you say MIT you think about ITS and Lisp. That is why emacs IMHO was against UNIX ideals. RMS was thinking in different terms than Bell Labs hackers. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170916/8ebb6252/attachment-0001.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-16 12:59 ` Ron Natalie 2017-09-16 18:19 ` Andy Kosela @ 2017-09-17 18:37 ` Chet Ramey 2017-09-18 15:11 ` Steve Johnson 1 sibling, 1 reply; 204+ messages in thread From: Chet Ramey @ 2017-09-17 18:37 UTC (permalink / raw) On 9/16/17 8:59 AM, Ron Natalie wrote: > RMS hates UNIX. That was clear in the original manifesto. But he's also > a megalomaniac and believes that if you even use a GNU tool your work > becomes his. Nah, this is BS. Stallman might not like Unix, and he clearly has a very large ego -- as do many of us here -- but that "belief" is just crap. The thing that comes closest to it is bison, and the output of bison is explicitly excluded. There is the issue of GPL libraries (like readline), and that's a pain for people who want to link with them, but that doesn't count as "even use a GNU tool." -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://cnswww.cns.cwru.edu/~chet/ ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-17 18:37 ` Chet Ramey @ 2017-09-18 15:11 ` Steve Johnson 0 siblings, 0 replies; 204+ messages in thread From: Steve Johnson @ 2017-09-18 15:11 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1985 bytes --] If imitation is the sincerest form of flattery, I suppose those of us who worked on Unix should be very flattered. I just wish they had imitated the programming style and sense of taste. The gcc _manual_ is 500 pages -- bigger than the entire Unix distribution. The options alone are almost 100 pages. The average line in the source code is an ifdef of some machine you've never heard of. If you are doing anything the slightest bit unusual (e.g., increasing the default stack size) you need a different option for each machine target. Hmm, I thought the point of C was to be portable... I recently started using clang, and I'm never going back to gcc. I feel so much cleaner now... Steve ----- Original Message ----- From: chet .ramey @case.edu To: "Ron Natalie" <ron @ronnatalie .com>, "Larry McVoy " <lm @mcvoy .com>, "Theodore Ts'o " <tytso @mit .edu > Cc: <tuhs @minnie .tuhs .org> Sent: Sun, 17 Sep 2017 14:37:59 -0400 Subject: Re: [TUHS ] Happy birthday, Dennis Ritchie ! On 9/16/17 8:59 AM, Ron Natalie wrote: > RMS hates UNIX. That was clear in the original manifesto. But he's also > a megalomaniac and believes that if you even use a GNU tool your work > becomes his. Nah, this is BS. Stallman might not like Unix, and he clearly has a very large ego -- as do many of us here -- but that "belief" is just crap. The thing that comes closest to it is bison, and the output of bison is explicitly excluded. There is the issue of GPL libraries (like readline ), and that's a pain for people who want to link with them, but that doesn't count as "even use a GNU tool." -- ``The lyf so short, the craft so long to lerne .'' - Chaucer ``Ars longa , vita brevis'' - Hippocrates Chet Ramey , UTech , CWRU chet @case.edu http ://cnswww .cns .cwru .edu /~chet / -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170918/2f11b6f0/attachment-0001.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-16 3:40 ` Larry McVoy 2017-09-16 7:45 ` Steve Nickolas 2017-09-16 12:59 ` Ron Natalie @ 2017-09-16 19:20 ` arnold 2017-09-17 1:43 ` Larry McVoy 2017-09-17 18:25 ` Chet Ramey 3 siblings, 1 reply; 204+ messages in thread From: arnold @ 2017-09-16 19:20 UTC (permalink / raw) Larry McVoy <lm at mcvoy.com> wrote: > The GNU guys have written very, very little code. Um, let's see: Bash. gawk. sed. grep. coreutils. binutils. gcc. ... Essentially everything that was used from the command line on a standard Unix system. All reimplemented from scratch. Many GNU maintainers are active (directly or indirectly) in the POSIX standard efforts which influences all Unix implementations. > They are all about the license, which is fine, but I get off the bus > when they are claiming credit for work they did not do. This not true of ALL the GNU project maintainers. Don't tar everyone with RMS's brush. 'nuff said, And, IMHO, all this is WAY off topic and probably should be brought to a close. Arnold ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-16 19:20 ` arnold @ 2017-09-17 1:43 ` Larry McVoy 2017-09-17 1:55 ` Jon Steinhart ` (2 more replies) 0 siblings, 3 replies; 204+ messages in thread From: Larry McVoy @ 2017-09-17 1:43 UTC (permalink / raw) I stand by my comment. I'm friends with the Cygnus folks, they would tend to agree with me I think. All that stuff you listed, can you list the things that the GNU/FSF people have funded? Because I think there is close to nothing. All of that stuff is stuff that came under the GNU umbrella but they didn't do the coding. I give credit to RMS for the GPL, that was cool. But claiming credit for stuff that GNU/FSF didn't do was not cool. On Sat, Sep 16, 2017 at 01:20:00PM -0600, arnold at skeeve.com wrote: > Larry McVoy <lm at mcvoy.com> wrote: > > > The GNU guys have written very, very little code. > > Um, let's see: Bash. gawk. sed. grep. coreutils. binutils. gcc. ... > Essentially everything that was used from the command line on a > standard Unix system. All reimplemented from scratch. > > Many GNU maintainers are active (directly or indirectly) in the > POSIX standard efforts which influences all Unix implementations. > > > They are all about the license, which is fine, but I get off the bus > > when they are claiming credit for work they did not do. > > This not true of ALL the GNU project maintainers. Don't tar everyone > with RMS's brush. > > 'nuff said, > > And, IMHO, all this is WAY off topic and probably should be brought > to a close. > > Arnold -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-17 1:43 ` Larry McVoy @ 2017-09-17 1:55 ` Jon Steinhart 2017-09-17 2:14 ` Warner Losh 2017-09-17 5:13 ` Ian Zimmerman 2017-09-17 5:19 ` arnold 2017-09-17 18:43 ` Chet Ramey 2 siblings, 2 replies; 204+ messages in thread From: Jon Steinhart @ 2017-09-17 1:55 UTC (permalink / raw) On Sat, Sep 16, 2017 at 01:20:00PM -0600, arnold at skeeve.com wrote: > > This not true of ALL the GNU project maintainers. Don't tar everyone > with RMS's brush. What are we supposed to to then? cpio? ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-17 1:55 ` Jon Steinhart @ 2017-09-17 2:14 ` Warner Losh 2017-09-17 2:18 ` Larry McVoy 2017-09-17 5:13 ` Ian Zimmerman 1 sibling, 1 reply; 204+ messages in thread From: Warner Losh @ 2017-09-17 2:14 UTC (permalink / raw) On Sat, Sep 16, 2017 at 7:55 PM, Jon Steinhart <jon at fourwinds.com> wrote: > On Sat, Sep 16, 2017 at 01:20:00PM -0600, arnold at skeeve.com wrote: > > > > This not true of ALL the GNU project maintainers. Don't tar everyone > > with RMS's brush. > > What are we supposed to to then? cpio? > I think libarchive has largely replaced all that and understands zip, lzh, etc. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170916/6c729829/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-17 2:14 ` Warner Losh @ 2017-09-17 2:18 ` Larry McVoy 2017-09-17 14:27 ` Warner Losh 0 siblings, 1 reply; 204+ messages in thread From: Larry McVoy @ 2017-09-17 2:18 UTC (permalink / raw) On Sat, Sep 16, 2017 at 08:14:47PM -0600, Warner Losh wrote: > On Sat, Sep 16, 2017 at 7:55 PM, Jon Steinhart <jon at fourwinds.com> wrote: > > > On Sat, Sep 16, 2017 at 01:20:00PM -0600, arnold at skeeve.com wrote: > > > > > > This not true of ALL the GNU project maintainers. Don't tar everyone > > > with RMS's brush. > > > > What are we supposed to to then? cpio? > > > > I think libarchive has largely replaced all that and understands zip, lzh, > etc. I think you missed Jon's joke. If you want more of that, check out this thread: https://www.reddit.com/r/IAmA/comments/70arwl/i_am_john_cleese_writer_actor_and_tall_person_ama/ ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-17 2:18 ` Larry McVoy @ 2017-09-17 14:27 ` Warner Losh 0 siblings, 0 replies; 204+ messages in thread From: Warner Losh @ 2017-09-17 14:27 UTC (permalink / raw) On Sat, Sep 16, 2017 at 8:18 PM, Larry McVoy <lm at mcvoy.com> wrote: > On Sat, Sep 16, 2017 at 08:14:47PM -0600, Warner Losh wrote: > > On Sat, Sep 16, 2017 at 7:55 PM, Jon Steinhart <jon at fourwinds.com> > wrote: > > > > > On Sat, Sep 16, 2017 at 01:20:00PM -0600, arnold at skeeve.com wrote: > > > > > > > > This not true of ALL the GNU project maintainers. Don't tar everyone > > > > with RMS's brush. > > > > > > What are we supposed to to then? cpio? > > > > > > > I think libarchive has largely replaced all that and understands zip, > lzh, > > etc. > > I think you missed Jon's joke. If you want more of that, check out this > thread: > > https://www.reddit.com/r/IAmA/comments/70arwl/i_am_john_ > cleese_writer_actor_and_tall_person_ama/ > I think you missed my "Why can't we all get along" moment :) Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170917/9706f8fb/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-17 1:55 ` Jon Steinhart 2017-09-17 2:14 ` Warner Losh @ 2017-09-17 5:13 ` Ian Zimmerman 1 sibling, 0 replies; 204+ messages in thread From: Ian Zimmerman @ 2017-09-17 5:13 UTC (permalink / raw) On 2017-09-16 18:55, Jon Steinhart wrote: > > This not true of ALL the GNU project maintainers. Don't tar everyone > > with RMS's brush. > > What are we supposed to to then? cpio? pax posixana! -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. Do obvious transformation on domain to reply privately _only_ on Usenet. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-17 1:43 ` Larry McVoy 2017-09-17 1:55 ` Jon Steinhart @ 2017-09-17 5:19 ` arnold 2017-09-17 18:49 ` Chet Ramey 2017-09-17 18:43 ` Chet Ramey 2 siblings, 1 reply; 204+ messages in thread From: arnold @ 2017-09-17 5:19 UTC (permalink / raw) RMS wrote GCC initially. And Emacs if that's what you use. And GDB initially as well. RMS did Texinfo (even if you don't like it yourself, it's a very nice markup language). Bash, gawk, sed, grep, coreutils were (and still are) maintained by unpaid volunteers, true, but they all were started for the GNU project. (Bash in the early days may have been funded by the FSF.) You're welcome to stand by your comment, but --- as a GNU maintainer for close to 30 years --- I think you paint with too broad a brush. More than enough said, Arnold Larry McVoy <lm at mcvoy.com> wrote: > I stand by my comment. I'm friends with the Cygnus folks, they would > tend to agree with me I think. > > All that stuff you listed, can you list the things that the GNU/FSF > people have funded? Because I think there is close to nothing. All of > that stuff is stuff that came under the GNU umbrella but they didn't do > the coding. > > I give credit to RMS for the GPL, that was cool. But claiming credit > for stuff that GNU/FSF didn't do was not cool. > > On Sat, Sep 16, 2017 at 01:20:00PM -0600, arnold at skeeve.com wrote: > > Larry McVoy <lm at mcvoy.com> wrote: > > > > > The GNU guys have written very, very little code. > > > > Um, let's see: Bash. gawk. sed. grep. coreutils. binutils. gcc. ... > > Essentially everything that was used from the command line on a > > standard Unix system. All reimplemented from scratch. > > > > Many GNU maintainers are active (directly or indirectly) in the > > POSIX standard efforts which influences all Unix implementations. > > > > > They are all about the license, which is fine, but I get off the bus > > > when they are claiming credit for work they did not do. > > > > This not true of ALL the GNU project maintainers. Don't tar everyone > > with RMS's brush. > > > > 'nuff said, > > > > And, IMHO, all this is WAY off topic and probably should be brought > > to a close. > > > > Arnold > > -- > --- > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-17 5:19 ` arnold @ 2017-09-17 18:49 ` Chet Ramey 2017-09-17 18:57 ` Kurt H Maier 0 siblings, 1 reply; 204+ messages in thread From: Chet Ramey @ 2017-09-17 18:49 UTC (permalink / raw) On 9/17/17 1:19 AM, arnold at skeeve.com wrote: > RMS wrote GCC initially. And Emacs if that's what you use. And GDB > initially as well. RMS did Texinfo (even if you don't like it yourself, > it's a very nice markup language). > > Bash, gawk, sed, grep, coreutils were (and still are) maintained by > unpaid volunteers, true, but they all were started for the GNU project. > (Bash in the early days may have been funded by the FSF.) I remember multiple FSF efforts to solicit volunteers for named projects. There were lots of people willing to donate their time and effort. And at that time, there were very few non-FSF projects licensed under the GPL, so the issue of "absorbtion" was minor to non-existent. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://cnswww.cns.cwru.edu/~chet/ ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-17 18:49 ` Chet Ramey @ 2017-09-17 18:57 ` Kurt H Maier 2017-09-17 19:08 ` Warner Losh 2017-09-17 19:22 ` Chet Ramey 0 siblings, 2 replies; 204+ messages in thread From: Kurt H Maier @ 2017-09-17 18:57 UTC (permalink / raw) On Sun, Sep 17, 2017 at 02:49:16PM -0400, Chet Ramey wrote: > > I remember multiple FSF efforts to solicit volunteers for named projects. > There were lots of people willing to donate their time and effort. And > at that time, there were very few non-FSF projects licensed under the GPL, > so the issue of "absorbtion" was minor to non-existent. But that time changed, and was replaced by a time where the FSF pushed hard on copyright assignment to the FSF, and led to a time where we wound up with GPL, GPL2, GPL3, AGPL, LGPL, ad infinitum, which landed us in the present day, where half the tech organizations on earth are so unwilling to step into the morass that BSD/MIT licenses are making a big comeback. They've spent so much time trying to 'fix' international patent law by clubbing people with copyright licenses that the company behind the most popular linux distribution is working on a BSD-licensed kernel. The history of UNIX and its ilk fascinates me, but only half of it is technology. The other half of it is a bizarre forty-year-long license war, which the partisans refuse to stop fighting, even after they win. khm ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-17 18:57 ` Kurt H Maier @ 2017-09-17 19:08 ` Warner Losh 2017-09-17 19:33 ` Bakul Shah 2017-09-17 19:22 ` Chet Ramey 1 sibling, 1 reply; 204+ messages in thread From: Warner Losh @ 2017-09-17 19:08 UTC (permalink / raw) On Sun, Sep 17, 2017 at 12:57 PM, Kurt H Maier <khm at sciops.net> wrote: > On Sun, Sep 17, 2017 at 02:49:16PM -0400, Chet Ramey wrote: > > > > I remember multiple FSF efforts to solicit volunteers for named projects. > > There were lots of people willing to donate their time and effort. And > > at that time, there were very few non-FSF projects licensed under the > GPL, > > so the issue of "absorbtion" was minor to non-existent. > > But that time changed, and was replaced by a time where the FSF pushed > hard on copyright assignment to the FSF, and led to a time where we > wound up with GPL, GPL2, GPL3, AGPL, LGPL, ad infinitum, which landed us > in the present day, where half the tech organizations on earth are so > unwilling to step into the morass that BSD/MIT licenses are making a big > comeback. > FreeBSD started out life with lots of GNU/GPL software. After GPLv3 was released, the project made a conscious effort to move away from all GPL'd software in the tree. When FreeBSD 12 comes out next year, there's a really good chance all the GPL'd code will be gone from the tree. > They've spent so much time trying to 'fix' international patent law by > clubbing people with copyright licenses that the company behind the most > popular linux distribution is working on a BSD-licensed kernel. > Fun times, that.... > The history of UNIX and its ilk fascinates me, but only half of it is > technology. The other half of it is a bizarre forty-year-long license > war, which the partisans refuse to stop fighting, even after they win. > Yea... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170917/5002e5bd/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-17 19:08 ` Warner Losh @ 2017-09-17 19:33 ` Bakul Shah 0 siblings, 0 replies; 204+ messages in thread From: Bakul Shah @ 2017-09-17 19:33 UTC (permalink / raw) > The history of UNIX and its ilk fascinates me, but only half of it is > technology. The other half of it is a bizarre forty-year-long license > war, which the partisans refuse to stop fighting, even after they win. > > Yea... Even discussions about GPL are viral! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170917/3a8175e1/attachment.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-17 18:57 ` Kurt H Maier 2017-09-17 19:08 ` Warner Losh @ 2017-09-17 19:22 ` Chet Ramey 1 sibling, 0 replies; 204+ messages in thread From: Chet Ramey @ 2017-09-17 19:22 UTC (permalink / raw) On 9/17/17 2:57 PM, Kurt H Maier wrote: > On Sun, Sep 17, 2017 at 02:49:16PM -0400, Chet Ramey wrote: >> >> I remember multiple FSF efforts to solicit volunteers for named projects. >> There were lots of people willing to donate their time and effort. And >> at that time, there were very few non-FSF projects licensed under the GPL, >> so the issue of "absorbtion" was minor to non-existent. > > But that time changed, and was replaced by a time where the FSF pushed > hard on copyright assignment to the FSF, and led to a time where we > wound up with GPL, GPL2, GPL3, AGPL, LGPL, ad infinitum, which landed us > in the present day, where half the tech organizations on earth are so > unwilling to step into the morass that BSD/MIT licenses are making a big > comeback. This is all true, though I would argue that the "copyright assignment to the FSF" was there from the beginning, and concealed by the fact that the early work was directly funded by the FSF before being handed off. Certainly they asked me for a copyright assignment early on, and this is almost 30 years ago. There just weren't that many objections. I would also argue that the different versions of the license were the result of people asking for exceptions or clarifiations, and the FSF attempting to accommodate them. There's no question that the GNU project is at least as much of a social policy effort as a technology one. You can't leave either one out of any history. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://cnswww.cns.cwru.edu/~chet/ ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-17 1:43 ` Larry McVoy 2017-09-17 1:55 ` Jon Steinhart 2017-09-17 5:19 ` arnold @ 2017-09-17 18:43 ` Chet Ramey 2017-09-18 0:12 ` Larry McVoy 2 siblings, 1 reply; 204+ messages in thread From: Chet Ramey @ 2017-09-17 18:43 UTC (permalink / raw) On 9/16/17 9:43 PM, Larry McVoy wrote: > I stand by my comment. I'm friends with the Cygnus folks, they would > tend to agree with me I think. > > All that stuff you listed, can you list the things that the GNU/FSF > people have funded? Because I think there is close to nothing. All of > that stuff is stuff that came under the GNU umbrella but they didn't do > the coding. Is that the only criterion? Whether or not someone got paid directly by the FSF to do something? Because there are lots of tools that were originally written by people funded by the FSF and then handed off to people like me: volunteers who donate our effort. > > I give credit to RMS for the GPL, that was cool. But claiming credit > for stuff that GNU/FSF didn't do was not cool. Denigrating the work of volunteers who explicitly donated their effort and talent to the FSF is not cool. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://cnswww.cns.cwru.edu/~chet/ ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-17 18:43 ` Chet Ramey @ 2017-09-18 0:12 ` Larry McVoy 2017-09-18 0:51 ` Clem Cole 0 siblings, 1 reply; 204+ messages in thread From: Larry McVoy @ 2017-09-18 0:12 UTC (permalink / raw) On Sun, Sep 17, 2017 at 02:43:33PM -0400, Chet Ramey wrote: > On 9/16/17 9:43 PM, Larry McVoy wrote: > > I stand by my comment. I'm friends with the Cygnus folks, they would > > tend to agree with me I think. > > > > All that stuff you listed, can you list the things that the GNU/FSF > > people have funded? Because I think there is close to nothing. All of > > that stuff is stuff that came under the GNU umbrella but they didn't do > > the coding. > > Is that the only criterion? Whether or not someone got paid directly by > the FSF to do something? Because there are lots of tools that were > originally written by people funded by the FSF and then handed off to > people like me: volunteers who donate our effort. > > > > > I give credit to RMS for the GPL, that was cool. But claiming credit > > for stuff that GNU/FSF didn't do was not cool. > > Denigrating the work of volunteers who explicitly donated their effort > and talent to the FSF is not cool. OK, let's hit the reset button on this one. I'm happy that the GNU project exists, I benefit from it every day. I am explicitly stating that I appreciate all of the work that people have done as volunteers, I'm one of them. What I'm not a fan of is Stallman getting people to put stuff under the GPL and then acting like he/FSF wrote the code. He still claims credit for GCC to this day and the Stallman GCC was *nothing* like a Ken C compiler, it was junk. Tiemann at Sun and then Cygnus, did the real work to make that thing actually be a reasonable program. Don't believe me? Go find a pre-Tiemann GCC and try and compile any reasonable program with it. As someone else pointed out, emacs wasn't RMS, it was Gosling. RMS has a track record of starting stuff, hijacking stuff, and claiming credit. That is what I don't like. I like the GNU project just fine, I'm not a fan of people claiming credit for stuff they didn't do. I really soured on on RMS when the FSF took my ls -h/du -h code and "rewrote" it so they would not have to give me credit. That's pretty petty. He did it because he hated me because BitKeeper wasn't open source enough for him and the kernel was using it. So he wanted to scrub the GNU source base of any of my contributions. So I stopped contributing. I'll leave you with a story from the Cygnus days, I was friends with all three founders. I was having dinner with Gumby and Michael and we were discussing RMS. It was RMS this, RMS that. Gumby's wife is German and at one point she says "OMG, you mean RMS!". We say "yeah?" She says all this time I thought you were saying "Our mess". We paused, replayed the conversation, and were sort of stunned that every sentence made sense with "our mess". ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-18 0:12 ` Larry McVoy @ 2017-09-18 0:51 ` Clem Cole 0 siblings, 0 replies; 204+ messages in thread From: Clem Cole @ 2017-09-18 0:51 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2095 bytes --] On Sun, Sep 17, 2017 at 8:12 PM, Larry McVoy <lm at mcvoy.com> wrote: > > OK, let's hit the reset button on this one. I agree, Warren said something similar... > I'm happy that the GNU > > project exists, I benefit from it every day. ditto. > I am explicitly stating > > that I appreciate all of the work that people have done as volunteers, > I'm one of them. And I'll add, we as a community owe a huge thank you to all of them, particularly many smaller less known folks that have helped out over the years. I wish I could thank them all specifically. I'll give RMS, Len and original GNU team credit for one really important thing that happened early on. It really was the getting a C compiler out that there that worked (sort of) for so many systems. This was the key enabler more than anything else. The C compiler that anyone could get, that was freely available, was the watershed moment for all us. [ And Larry's right, the fact the Tiemann mopped up an d really move d it from being a toy to being something that was pretty creditable, it what made the project actually have a long term life ] . If we had not had the compiler, almost all other project would not have happened. By getting a compiler that covered the primary architectures being used and was quickly moved to so many OS's and generated 'good enough' code for so many folks - we have the options we have today. The only other compiler at the time, that could have done the same things was Andy's Amsterdam Compiler Kit (which when it came out, was considered a "better" compiler), but it had a small pay wall. And 'free' as in 'beer' was the important difference when it all started. Like many of other Christiansen style disruptions.... 'worse' technology was valuable and got better. And the GNU C disrupted the order in the software industry. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170917/bdd92b6e/attachment-0001.html> ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-16 3:40 ` Larry McVoy ` (2 preceding siblings ...) 2017-09-16 19:20 ` arnold @ 2017-09-17 18:25 ` Chet Ramey 3 siblings, 0 replies; 204+ messages in thread From: Chet Ramey @ 2017-09-17 18:25 UTC (permalink / raw) On 9/15/17 11:40 PM, Larry McVoy wrote: > As well it should be. My colors are showing here, but I'm really sick > of the FSF slapping their name on other people's work. If Stallman > wants it to be called GNU/Linux let him write a kernel. He didn't, > he can't, yet he wants credit. I got pretty disgusted back in the day > when everything that was GPLed suddenly became a GNU project. The GNU > guys have written very, very little code. > > They are all about the license, which is fine, but I get off the bus > when they are claiming credit for work they did not do. You are associating not having a lot of paid employees with not having a lot of people do work under the FSF banner. That's not close to true. It's true that the FSF had few full-time employees. They worked off grants. It's not true that these folks didn't produce a lot of work: they did. It's true that the volunteers who donated their work to the FSF did so fully understanding what they were doing. Arnold and I have first-hand experience here. It's true that there were a number of projects that petitioned to come under the FSF umbrella, and were accepted. It's not true that everything released under the GPL became part of the GNU project and was listed on www.gnu.org/software. I get that you don't like the FSF model, but the organization and its volunteers produced -- and continue to produce -- a significant body of good work. Linux as people think of it today (no, it's not just a kernel) really wouldn't exist without it. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://cnswww.cns.cwru.edu/~chet/ ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] @ 2017-09-19 12:24 Norman Wilson 2017-09-19 18:09 ` Random832 0 siblings, 1 reply; 204+ messages in thread From: Norman Wilson @ 2017-09-19 12:24 UTC (permalink / raw) Random832: Just out of curiosity, where does perror(filename), quite possibly the *most* common error message on Unix as a whole, fall on your scale? It says which of the file location or permissions (or whatever else) it is, but not whether it was attempting to open it for reading or writing. ===== I never liked perror much. It's a little too primitive: you get exactly one non-formatted string; you get only stderr, so if you're sending messages separately to a log or writing them to a network connection or the like, you're out of luck. strerror(errno) hits the sweet spot for me. Until it appeared in the standard library (and until said standard spread enough that one could reasonably expect to find it anywhere) I kept writing more or less that function into program after program. I guess the problem with perror is that it isn't sufficiently UNIX-like: it bundles three jobs that are really separate (convert errno to string message, format an error message, output the message) into one function, inseparably and inflexibly. Norman Wilson Toronto ON ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-19 12:24 [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] Norman Wilson @ 2017-09-19 18:09 ` Random832 2017-09-19 19:21 ` Chris Torek 0 siblings, 1 reply; 204+ messages in thread From: Random832 @ 2017-09-19 18:09 UTC (permalink / raw) On Tue, Sep 19, 2017, at 08:24, Norman Wilson wrote: > I guess the problem with perror is that it isn't sufficiently > UNIX-like: it bundles three jobs that are really separate > (convert errno to string message, format an error message, > output the message) into one function, inseparably and > inflexibly. Yeah, but you have to do all of that (plus exit, if the error isn't recoverable) after every single function that might fail. If the function didn't exist, you'd have to write your own, so you're not really any worse off if it doesn't do quite what you want. if(open one thing < 0) { perror...; exit...; } if(open another thing < 0) { perror...; exit...; } if(!malloc...) {perror... exit... } etc, I'd be half tempted to write a function just for *that*. BSD's err/warn family is a further refinement on this - it allows format/arguments, as I complained about in another post, and lets you specify what file to send output to, and the existence of err vs warn lets you avoid having exit as a separate step. ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-19 18:09 ` Random832 @ 2017-09-19 19:21 ` Chris Torek 0 siblings, 0 replies; 204+ messages in thread From: Chris Torek @ 2017-09-19 19:21 UTC (permalink / raw) >BSD's err/warn family is a further refinement on this - it allows >format/arguments, as I complained about in another post ... Yes, which is why I pushed for having something like this. The final implementation (err, errx, warn, warnx) is not quite what I had suggested (I had an error-exit-code that, if 0, meant this was a warning, i.e., don't exit) but the essence is all there. >and lets you specify what file to send output to, It does now. That was not in the original. It's a good idea though. >and the existence of err vs warn lets you avoid having >exit as a separate step. I still like my "exit code" argument with zero for warn, since it pushes one towards a nonzero exit for all errors. Chris ^ permalink raw reply [flat|nested] 204+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]
@ 2017-09-21 17:46 Norman Wilson
0 siblings, 0 replies; 204+ messages in thread
From: Norman Wilson @ 2017-09-21 17:46 UTC (permalink / raw)
On Tue, Sep 19, 2017, at 10:42, Larry McVoy wrote:
> slib.c:1653 (bk-7.3): open failed: permission denied
>
> which is way way way more useful than just permission denied.
Random832 replied:
Well. It's less useful in one way - it doesn't say what file it was
trying to open. You could pass the filename *instead* of "open failed",
but that still omits the issue I had pointed out: what were you trying
to open the file for (at the very least, were you trying to read, write,
or exec it). Ideally the function would have a format and arguments.
====
Exactly.
The string interpretation of errno is just another
item of data that goes in an error message. There is
no fixed place it belongs, and it doesn't always
belong there, because all that is error does not
fail from a syscall (or library routine).
I do often insert a function of the form
void errmsg(char *, ...)
in my C programs. It takes printf-like arguments.
Normally they just get passed to vfprintf(stderr, ...),
though sometimes there is something more esoteric,
and often fprintf(stderr, "%s: ", progname) ends up
in front.
But errmsg never knows anything about errno. Why
should it? It's supposed to send complaints to
a standard place; it's not supposed to invent the
complaints for itself! If an errno is involved,
I write something like
errmsg("%s: cannot open: %s", filename, strerror(errno));
(Oh, yes, errmsg appends a newline too. The idea
is to avoid cluttering code with minutiae of how
errors are reported.)
I don't print the source code filename or line number
except for `this shouldn't have happened' errors.
For routine events like the user gave the wrong
filename or it had the wrong permissions or his
data are malformed, pointers to the source code are
just unhelpful clutter, like the complicated
%JARGON-OBSCURE-ABBREVIATION prefixes that accompanied
every official error message in VMS.
Of course, if the user's data are malformed, he
should be told which file has the problem and
where in the file. But that's different from
telling him that line 193 of some file he doesn't
have and will probably never see contains the system
call that reported that he typed the wrong filename.
Norman Wilson
Toronto ON
^ permalink raw reply [flat|nested] 204+ messages in thread
end of thread, other threads:[~2017-09-23 22:24 UTC | newest] Thread overview: 204+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-09-08 20:54 [TUHS] Happy birthday, Dennis Ritchie! Dave Horsfall 2017-09-08 21:04 ` Noel Chiappa 2017-09-08 21:09 ` Michael Kjörling 2017-09-09 1:16 ` Wesley Parish 2017-09-09 1:30 ` [TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!) Greg 'groggy' Lehey 2017-09-09 1:43 ` Warner Losh 2017-09-09 1:50 ` Wesley Parish 2017-09-09 13:59 ` [TUHS] File-as-record Arthur Krewat 2017-09-11 17:26 ` [TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!) Paul Winalski 2017-09-09 4:34 ` [TUHS] Happy birthday, Dennis Ritchie! Steve Johnson 2017-09-09 13:04 ` William Cheswick 2017-09-09 17:26 ` Steve Nickolas 2017-09-09 17:49 ` Arthur Krewat 2017-09-09 19:40 ` Steve Nickolas 2017-09-09 20:33 ` Lawrence Stewart 2017-09-09 21:56 ` Steve Johnson 2017-09-10 1:27 ` Dave Horsfall 2017-09-11 16:20 ` Paul Winalski 2017-09-09 15:55 ` Clem Cole 2017-09-08 22:28 ` Steve Nickolas 2017-09-09 11:04 ` Michael Kjörling 2017-09-09 11:19 ` Steve Nickolas 2017-09-08 21:05 ` Arthur Krewat 2017-09-08 21:14 ` William Pechter 2017-09-08 22:13 ` Angus Robinson 2017-09-08 23:11 ` William Pechter 2017-09-09 5:13 ` Dave Horsfall 2017-09-09 15:41 ` Larry McVoy 2017-09-09 4:20 ` Dave Horsfall 2017-09-11 16:30 ` Paul Winalski 2017-09-11 16:49 ` [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo ] Jon Steinhart 2017-09-11 17:37 ` Paul Winalski 2017-09-11 23:09 ` Larry McVoy 2017-09-12 7:38 ` arnold 2017-09-12 14:12 ` Ronald Natalie 2017-09-12 14:51 ` Toby Thain 2017-09-12 15:33 ` arnold 2017-09-12 15:35 ` [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] Jon Steinhart 2017-09-12 16:57 ` Larry McVoy 2017-09-12 17:04 ` Arthur Krewat 2017-09-12 17:07 ` Larry McVoy 2017-09-12 22:11 ` [TUHS] X and NeWS history (long) Jon Steinhart 2017-09-12 22:58 ` Larry McVoy 2017-09-12 23:22 ` Jon Steinhart 2017-09-12 23:44 ` Chris Torek 2017-09-12 23:41 ` Adam Sampson 2017-09-13 0:14 ` Jon Steinhart 2017-09-13 16:38 ` [TUHS] old X versions (was:X and NeWS history) Christian Groessler 2017-09-13 19:10 ` Kurt H Maier 2017-09-13 19:13 ` Henry Bent 2017-09-19 0:44 ` Random832 2017-09-19 10:30 ` Nigel Williams 2017-09-19 14:05 ` Jon Steinhart 2017-09-19 15:16 ` Gregg Levine 2017-09-19 15:39 ` [TUHS] old X versions Chet Ramey 2017-09-19 18:23 ` Nemo 2017-09-19 18:32 ` Clem Cole 2017-09-19 18:32 ` Chet Ramey 2017-09-19 18:34 ` Jon Steinhart 2017-09-19 18:43 ` Chet Ramey 2017-09-19 19:19 ` Stephen Kitt 2017-09-19 15:40 ` [TUHS] old X versions (was:X and NeWS history) Clem Cole 2017-09-19 17:01 ` Steve Nickolas 2017-09-19 17:15 ` Gregg Levine 2017-09-19 18:56 ` Derek Fawcus 2017-09-19 19:22 ` [TUHS] old X versions Arthur Krewat 2017-09-19 20:15 ` [TUHS] old X versions (was:X and NeWS history) Gregg Levine 2017-09-19 18:30 ` Nemo 2017-09-19 23:40 ` Wesley Parish 2017-09-19 23:46 ` [TUHS] old X versions Grant Taylor 2017-09-20 0:06 ` Arthur Krewat 2017-09-13 0:29 ` [TUHS] X and NeWS history (long) Bakul Shah 2017-09-13 0:52 ` ron minnich 2017-09-13 0:54 ` Warner Losh 2017-09-13 0:56 ` ron minnich 2017-09-13 0:57 ` Warner Losh 2017-09-13 2:06 ` Kurt H Maier 2017-09-13 3:34 ` ron minnich 2017-09-13 3:55 ` Jon Steinhart 2017-09-13 15:16 ` Arthur Krewat 2017-09-13 15:42 ` [TUHS] X and NeWS history (long) [ really systemd, student access to real code ] Jon Steinhart 2017-09-13 1:42 ` [TUHS] X and NeWS history (long) Arthur Krewat 2017-09-13 2:27 ` Grant Taylor 2017-09-13 16:14 ` Lawrence Stewart 2017-09-13 0:56 ` Jon Steinhart 2017-09-13 1:34 ` Bakul Shah 2017-09-13 2:43 ` Grant Taylor 2017-09-13 3:01 ` Jon Steinhart 2017-09-13 3:25 ` Grant Taylor 2017-09-13 3:27 ` Jon Steinhart 2017-09-13 15:09 ` Tony Finch 2017-09-13 15:19 ` Jon Steinhart 2017-09-12 23:33 ` [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] Dave Horsfall 2017-09-12 20:15 ` Steve Johnson 2017-09-13 2:23 ` Larry McVoy 2017-09-14 0:53 ` Nemo 2017-09-14 1:18 ` Henry Bent 2017-09-14 3:15 ` Larry McVoy 2017-09-14 9:35 ` Rico Pajarola 2017-09-14 11:11 ` arnold 2017-09-14 12:13 ` Rico Pajarola 2017-09-14 12:50 ` Chet Ramey 2017-09-14 13:27 ` Rico Pajarola 2017-09-14 14:30 ` Chet Ramey 2017-09-14 13:21 ` Steffen Nurpmeso 2017-09-14 19:44 ` arnold 2017-09-14 20:22 ` [TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ] Jon Steinhart 2017-09-14 20:32 ` Ron Natalie 2017-09-14 21:00 ` Chris Torek 2017-09-14 21:03 ` Ron Natalie 2017-09-14 22:26 ` Grant Taylor 2017-09-16 3:34 ` Larry McVoy 2017-09-16 4:16 ` Warner Losh 2017-09-16 5:08 ` Dave Horsfall 2017-09-16 3:33 ` Larry McVoy 2017-09-14 20:41 ` Bakul Shah 2017-09-14 21:00 ` Noel Hunt 2017-09-15 17:42 ` [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] Steffen Nurpmeso 2017-09-14 20:31 ` Ian Zimmerman 2017-09-15 3:16 ` Dave Horsfall 2017-09-15 3:33 ` Warner Losh 2017-09-15 8:32 ` Ron Natalie 2017-09-15 12:42 ` Arthur Krewat 2017-09-15 18:20 ` Steffen Nurpmeso 2017-09-15 18:37 ` Paul Winalski 2017-09-13 7:30 ` arnold 2017-09-13 13:35 ` Larry McVoy 2017-09-13 23:55 ` Dave Horsfall 2017-09-14 0:18 ` Henry Bent 2017-09-14 2:10 ` Larry McVoy 2017-09-14 19:37 ` Steve Johnson 2017-09-14 19:54 ` Steve Nickolas 2017-09-14 20:50 ` Ian Zimmerman 2017-09-14 21:00 ` Ron Natalie 2017-09-14 20:11 ` Ron Natalie 2017-09-14 20:26 ` Jon Steinhart 2017-09-19 0:52 ` Random832 2017-09-19 2:50 ` Larry McVoy 2017-09-19 2:56 ` Gregg Levine 2017-09-19 3:37 ` Larry McVoy 2017-09-19 6:52 ` Lars Brinkhoff 2017-09-19 7:22 ` Ian Zimmerman 2017-09-19 13:22 ` Larry McVoy 2017-09-19 13:53 ` Steffen Nurpmeso 2017-09-19 13:56 ` Larry McVoy 2017-09-19 17:56 ` Random832 2017-09-19 18:31 ` Steffen Nurpmeso 2017-09-19 18:34 ` Larry McVoy 2017-09-19 19:31 ` Lawrence Stewart 2017-09-20 3:13 ` Larry McVoy 2017-09-23 22:24 ` Ralph Corderoy 2017-09-19 14:32 ` Clem Cole 2017-09-19 14:42 ` Larry McVoy 2017-09-19 15:12 ` Clem Cole 2017-09-19 18:03 ` Random832 2017-09-10 9:44 ` [TUHS] Happy birthday, Dennis Ritchie! arnold 2017-09-13 23:22 ` Dave Horsfall 2017-09-14 16:11 ` Ian Zimmerman 2017-09-14 16:15 ` Steve Nickolas 2017-09-14 19:30 ` Theodore Ts'o 2017-09-14 19:52 ` Steve Nickolas 2017-09-14 22:03 ` Christian Groessler 2017-09-14 22:39 ` Erik Berls 2017-09-14 22:52 ` ron minnich 2017-09-14 23:04 ` Warner Losh 2017-09-14 23:14 ` Bakul Shah 2017-09-15 19:01 ` Chris Torek 2017-09-15 19:50 ` Lyndon Nerenberg 2017-09-15 19:56 ` ron minnich 2017-09-15 20:34 ` Chris Torek 2017-09-14 23:06 ` Bakul Shah 2017-09-15 0:47 ` ron minnich 2017-09-14 19:39 ` Kurt H Maier 2017-09-14 20:09 ` [TUHS] Happy birthday, Dennis Ritchie! [ really Pottering vs UNIX ] Jon Steinhart 2017-09-14 21:35 ` [TUHS] Happy birthday, Dennis Ritchie! Theodore Ts'o 2017-09-15 1:40 ` Ron Natalie 2017-09-15 14:04 ` Larry McVoy 2017-09-16 3:40 ` Larry McVoy 2017-09-16 7:45 ` Steve Nickolas 2017-09-16 12:59 ` Ron Natalie 2017-09-16 18:19 ` Andy Kosela 2017-09-17 18:37 ` Chet Ramey 2017-09-18 15:11 ` Steve Johnson 2017-09-16 19:20 ` arnold 2017-09-17 1:43 ` Larry McVoy 2017-09-17 1:55 ` Jon Steinhart 2017-09-17 2:14 ` Warner Losh 2017-09-17 2:18 ` Larry McVoy 2017-09-17 14:27 ` Warner Losh 2017-09-17 5:13 ` Ian Zimmerman 2017-09-17 5:19 ` arnold 2017-09-17 18:49 ` Chet Ramey 2017-09-17 18:57 ` Kurt H Maier 2017-09-17 19:08 ` Warner Losh 2017-09-17 19:33 ` Bakul Shah 2017-09-17 19:22 ` Chet Ramey 2017-09-17 18:43 ` Chet Ramey 2017-09-18 0:12 ` Larry McVoy 2017-09-18 0:51 ` Clem Cole 2017-09-17 18:25 ` Chet Ramey 2017-09-19 12:24 [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] Norman Wilson 2017-09-19 18:09 ` Random832 2017-09-19 19:21 ` Chris Torek 2017-09-21 17:46 Norman Wilson
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).