* [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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! @ 2017-09-08 20:54 Dave Horsfall 2017-09-08 21:14 ` William Pechter 0 siblings, 1 reply; 60+ 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] 60+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-08 20:54 [TUHS] Happy birthday, Dennis Ritchie! Dave Horsfall @ 2017-09-08 21:14 ` William Pechter 2017-09-11 16:30 ` Paul Winalski 0 siblings, 1 reply; 60+ 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] 60+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! 2017-09-08 21:14 ` William Pechter @ 2017-09-11 16:30 ` Paul Winalski 2017-09-11 16:49 ` [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo ] Jon Steinhart 0 siblings, 1 reply; 60+ 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] 60+ 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 23:09 ` Larry McVoy 0 siblings, 1 reply; 60+ 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] 60+ 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 23:09 ` Larry McVoy 2017-09-12 7:38 ` arnold 0 siblings, 1 reply; 60+ 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] 60+ 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 15:35 ` [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] Jon Steinhart 0 siblings, 1 reply; 60+ 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] 60+ 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 15:35 ` Jon Steinhart 2017-09-12 16:57 ` Larry McVoy ` (2 more replies) 0 siblings, 3 replies; 60+ 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] 60+ 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; 60+ 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] 60+ 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 2017-09-12 23:33 ` Dave Horsfall 2017-09-12 20:15 ` Steve Johnson 2 siblings, 2 replies; 60+ 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] 60+ 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 23:33 ` Dave Horsfall 1 sibling, 0 replies; 60+ 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] 60+ 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 23:33 ` Dave Horsfall 1 sibling, 0 replies; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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-15 17:42 ` Steffen Nurpmeso 2017-09-14 20:31 ` Ian Zimmerman 1 sibling, 1 reply; 60+ 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] 60+ messages in thread
* [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ] 2017-09-14 19:44 ` arnold @ 2017-09-15 17:42 ` Steffen Nurpmeso 0 siblings, 0 replies; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ 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; 60+ 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] 60+ messages in thread
end of thread, other threads:[~2017-09-23 22:24 UTC | newest] Thread overview: 60+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 -- strict thread matches above, loose matches on Subject: below -- 2017-09-21 17:46 Norman Wilson 2017-09-08 20:54 [TUHS] Happy birthday, Dennis Ritchie! Dave Horsfall 2017-09-08 21:14 ` William Pechter 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 23:09 ` Larry McVoy 2017-09-12 7:38 ` 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 23:33 ` 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-15 17:42 ` 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
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).