If no Unix... No Mac OSx or Linux or *BSD. Linux came from the Posix spec. OSx came from a Unix personality on Mach... Perhaps the Prime OS or perhaps Domain OS from Apollo would have been the workstation of the tech world. Apollo had a lead on Sun back in the day. Bill Bill -----Original Message----- From: Angus Robinson <angus(a)fairhaven.za.net> To: William Pechter <pechter(a)gmail.com>, The Eunuchs Hysterical Society <tuhs(a)tuhs.org>, Dave Horsfall <dave(a)horsfall.org> Sent: Fri, 08 Sep 2017 18:14 Subject: Re: [TUHS] Happy birthday, Dennis Ritchie! You also would have Mac OS, Linux,etc On Fri, Sep 8, 2017 at 5:14 PM William Pechter <pechter(a)gmail.com> wrote:

On Sat, Sep 09, 2017 at 03:13:30PM +1000, Dave Horsfall wrote: Mr Yacc might like this story. Before I worked for Sun I worked for Lachman (porting Unix to the ETA-10) and the dev environment there was apollos served by a Sun 3/280 file server. I was fresh out of school, interviewed with Lachman for this job, they sort of let me believe I'd be doing the VM system for this weird ass machine that was basically a cluster with a huge (at the time) 2GB "shared" memory that was bcopy only. Seemed like a fun project. I got there and they said "Um, you know, we have someone with more than zero years of experience working on the VM system. How about you port all the commands?" Crushed me was like "Really?" They said "Really". Sigh, whatever. So what I quickly learned was weird about this machine was that native pointers pointed at bits. The compiler writers were all like "fuck that, we point at bytes" but they had to have a way to get to real pointers so they decided that if you did char *p = &whatever; int i = (int)p; the assignment of a pointer into an int did the shift to point at the first bit of that byte, and the other way shifted the other way. Got it? Ints held "real" pointers and pointers held byte aligned pointers. It was weird, yes. The unfortunate side effect is that char *p = malloc(10); caused a shift if you didn't include malloc.h. Because the compiler thought malloc was returning a bit pointer so it "kindly" did the shift for us. This quickly became a pattern. Here is what I did: First, and this is the apollo part, I ported the cross compiler from the apollo environment to SunOS. Because compiling on the file server was faster in two ways: (a) local file system instead of NFS and (b) the Sun was way way faster than those stupid apollo machines. And the Sun was real Unix. The port caused all sorts of fuss because I wasn't part of the compiler team, I had to write a tool that diffed the binaries produced by the Sun with the ones produced by the apollos to show that the only difference was in the a.out header that had a timestamp or something. Second, and this is the part that Steve might like, I hacked lint suck that when it complained about type mismatches it wandered around until it got to the base types and printed out type mismatch: "INT" vs "POINTER" which wasn't that easy, I didn't really understand the guts of lint. I think those changes did wind their way back into Sys V lint somehow, I had nothing to do with it, maybe someone from Lachman fed them back or maybe the Sys V people redid them on their own. OK, so now I lint all of /usr/src/cmd and I wrote an awk script (perl wasn't around yet and awk worked fine) that looked for any int/pointer mismatch, edited the file, and included every header I could think of that declared some library function that returned a pointer, string.h, malloc.h, etc. I iterated a few times (this was an overnight thing, I'd come in in the morning and see that I forgot some more, add them to the list, restart the script). Finally I get a clean lint run and I start up a compile run, fix up a few remaining things (there were surprisingly few, it was an easy port) and I've got a built /usr/src/cmd installed on piper1, my test machine. I go to my boss and say "I'm done". Note that all of this stuff, getting onboarded, porting the compiler, wacking lint, linting, compiling, took about 3 weeks. I was a busy little beaver :) My boss goes "yeah, right. Hey, Mike, go look at piper1 and see what kind of a mess we have". Mike goes off and comes back, gives me a weird look, and says "He's right, he's done". Sort of, we didn't have tty's yet so vi didn't work, we didn't have a kmem driver so ps didn't work (which was *really* annoying), etc. But awk worked, find worked, ls worked, all that stuff worked. My boss says "get out of here, let me think about this". I come back in the next day, go to my boss (Bob Palm if any of you know him, great guy) and he says "You can go home, we'll just pay you". Turns out that Lachman had budgeted for 6 months to do the /usr/src/cmd port and it didn't look good to have me sitting around doing nothing. I, being the nerd that I am, said "Do you mind if I stick around if I'm doing work?" Bob says "Go for it, you can do whatever you want if you look busy". And there began the most awesome 6 months of my life. I wrote my own version of ps and a /dev/ps driver that was a dumbed down version of /dev/kmem, because I was too clueless to write a kmem driver. People used that ps for a long time until someone did a real kmem driver. I wrote the Unix side of the disk driver, which sounds hard but wasn't, this thing had I/O channels that had their own processor so it was more like writing a http client or something, just in the kernel. The real driver was in the I/O channel, all I had to do was learn how to talk to the I/O channel. And it was a polling driver, no interrupts, there was some hardware glitch with interrupts or something, whatever the reason, I just polled so it was easy. Shitty perf but easy. I ported all of the Lachman STREAMS TCP stack. If I recall correctly shorts weren't shorts, they were u32. So all the unsigned short port; became unsigned short port:16; I remember the stack being the biggest job, there were some things that turned out to be tricky, long forgotten. Oh, I bet anything a lot of it was the networking drivers. I know some of it was me banging on stuff but I think there were some driver issues as well, I didn't work on those, I'm not much of a device driver person. After all this I got sent to Japan with 3 source tapes, the base system that included all of /usr/src/cmd and everyone else's stuff that had sort of been approved for integration, a version of the tree with big pages, and the version of the tree that had the networking stack in it. I was sent to the Tokyo Institute of Technology (TIT) and I was the techy guy, they sent me with another Sun 3/280 and two Sun 3/50 (screw that apollo crud) and told me to set up a dev environment and merge those source trees. So of course the server was installed as "bigtit" and the 3/50's as "lefttit" and "righttit" which lasted until the Japanese folks figured out what those meant. I was there for 3 months, doing the merge wasn't easy and then other problems cropped, again with the drivers if I remember correctly. So the folks back in St Paul were sending me stuff, I was merging it, building, installing, testing, reporting back what didn't work, and that went on for quite a while. Eventually it worked and home I went. Lost a bunch of weight because I didn't like sushi at the time and there weren't a lot of good alternatives that kept my weight up. Fun times.

On 9/8/17, William Pechter <pechter(a)gmail.com> wrote: 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.

On 9/11/17, Jon Steinhart <jon(a)fourwinds.com> wrote: Absolutely. I worked at DEC and had many engineer friends at Apollo, and we were all shaking our heads wondering how Sun got their manufacturing costs so low. Scott McNealy's management style helped, too. Ken Olsen at DEC believed in consensus building; decisions weren't final until everyone bought into them. IMO this led to a lot of (expensive) wrangling and slowed down corporate reaction to market conditions. Scott McNealy believed in the principle of a single decision-maker: "lead, follow, or get out of the way". We at DEC eventually moved to project management that involved a single lead engineer who was responsible for the success of the project, and who was empowered to make decisions when a consensus couldn't be found. But that management style never really caught on, although in my experience the most successful software projects were all organized that way. -Paul W.

Larry McVoy <lm(a)mcvoy.com> wrote: 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

On 2017-09-12 10:12 AM, Ronald Natalie wrote: It would probably befit this list and posterity to go into detail about what those issues were. At the time, NeWS certainly seemed to have interesting ideas far ahead of the popular window systems (and yes we could discuss those ideas as well. Unfortunately my NeWS developer binder is in storage and my memory isn't reliable at that range). --T

arnold(a)skeeve.com writes: 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. 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(a)ronnatalie.com writes: 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

Oh, do, please go on ;) On 9/12/2017 11:35 AM, Jon Steinhart wrote:

Arthur Krewat writes: Larry McVoy writes: OK, you asked for it. I think that I need to ask the Thing King to zark in a few crates of old memories... I spent mt teenage years as a graphics person as a result of my summer job at Murray Hill working on the Glance-G terminal project. Side-tracked into test and measurement after getting my EE degree and doing cool black magic electronics at Tektronix. Got back into graphics and software when Tek tried to get into the UNIX workstation business. Started working on window systems at that time, and continued after I quit Tek and moved to the bay area to play at the startup game. Started consulting after the third startup failed which I'm still doing today. While at Tek one of my jobs was to come up with a C language binding for GKS, the Graphical Kernel System standard. That itself is a funny story which ties into the earlier troff thread. I designed a language binding and wrote it up. My friend Ed, author of "Real Programmers Don't Use Pascal", worked down the road at GSS (Graphics Software Systems). He told me that "yours looks better than ours, you should bring it to the standards committee". Amazingly enough my management bought off on it, I brought my draft to the Huntsville meeting, and it was adopted as the draft standard. Why? Because we had troff and an Imprint-10! Those were the days when people equated typeset with professional. I recall discussing the issues with the C binding at an ANSI C committee meeting in San Franscisco; probably met some you there. ANSI X3X3 formed a window management subcommittee X3H3.6 somewhere along the line. I moved over there as I was pretty much done with the GKS stuff and the window management end of things was more interesting. Life changed in that committee when the X push happened. But first, a bit on a parallel track. I knew Keith Lantz at Stanford who, if I remember correctly, had a graduate seminar and wanted to talk about window management systems. I came in as a guest lecturer. Partly because of this I became aware of the origins of X as those weren't the days when one could easily just get technical papers on line. For those of you unfamiliar with this, Stanford had developed the V operating system which featured very fast synchronous IPC. I believe that this ran on the original Stanford University Network (SUN) boards. They also developed the W window system which ran on top of V. I'm a bit fuzzy on the continental shift, but I believe that W made the cross country trip to MIT via some sort of DEC connection. Maybe they had funded some of the Stanford research. Gosling and Rosenthal had been working on the Andrew window system at CMU. I don't remember whether or not this was UNIX-based, but one of their early design decisions was to minimize round-trips because they didn't have fast synchronous IPC. Despite this prior art, Scheifler took the W code, ported it to UNIX, and called it X. As one would expect, the performance was terrible. X got stuck at this state, version 10, for a long time. Sun announced NeWS during this stagnant period. Freaked out Apollo, DEC, HP, etc. who got together at DEC's Hamilton Avenue building to plot the "anything but Sun" strategy. They were successful in holding off the adoption of NeWS until they could rewrite X to eliminate many of the synchronous round trips from the protocol resulting in X version 11 which was pretty much completely incompatible with version 10. In many respects Sun botched NeWS politically. Large numbers of businesses relied on applications that ran on Sun's SunView window system which was heavily hooked into the OS and not even remotely portable. They couldn't use NeWS instead of SunView because they were running real businesses. There was no way to run SunView and NeWS at the same time so businesses couldn't run new NeWS-based applications and old SunView applications at the same time. I'm a bit fuzzy here, but the decision to merge X and NeWS was a bad technical solution to a political problem. Sun wanted to be able to say "We have X too." Unfortunately, folks at Sun agreed to do this project without knowing what they were talking about; it got rough when they realized that the NeWS and X graphics models were completely incompatible. Oh, despite all of the hype, there was actually nothing useful that one could do using X at the time. Not being very well socially adjusted, I annoyed a lot of people by going to show floors and looking at X running things like maze and loudly proclaiming "Oh, that's exactly what I do for a living." Somewhere along the line Sun also decided to produce a mostly automated system to convert SunView programs to use X. I think that this was called XView. I remember billing for many a late night to actually get the thing working. One of my other clients at the time was AED (advanced electronic displays). If you were lucky enough to have a color frame buffer in those days it was likely one of theirs. They had a project to build X accelerator boards that plugged into Sun workstations. I think that I got called in because it wouldn't work on the 3/260 which I eventually tracked down to the behavior of the cache that only the 260 had. AED was trying to figure out what to do as the world had changed and frame buffers couldn't compete with workstations. I came up with the idea to make an X server that would run in a SunView window so that companies that relied on SunView applications could run X applications concurrently. We called this XTool in keeping with the SunView application naming scheme. I think that I still have a few "XTool - Safe X for Suns" tee shirts around somewhere. This project unfortunately failed because AED was bought by someone with a "ship it now, that'll force folks to fix the bugs" attitude. XTool was very small and fast compared to the X sample server because I wrote the server from scratch. I think that I'm the only person to write an X server outside of the X Consortium. One of the things that I learned by doing it was that the X Consortium folks were wrong when they said that the documentation was the standard, not the sample server. There were significant differences between the two. We showed XTool off at some shows. People would come by the booth and ask "how did you get it to run so fast?" Being me, I loudly answered "We cheated. We designed ours first." Turns out that one of these times Keith Packard and Jim Gettys were walking by which resulted in some long-standing animosity. Back to the standards track. Any of you that have done ANSI work know that CBEMA has a one organization, one vote policy. When Scheifler showed up at X3H3.6 all other work stopped and X became a draft standard. Whenever there was a vote everybody would look to see how Bob was voting and voted with him. For political reasons, all of the voting members from X Consortium member companies had been told that they couldn't vote against X for technical reasons. You may also know that one has to pay to be on an ANSI committee. I wrote the ANSI Secretariet and told them that I felt that by having both the X Consortium and their member companies voting violated the spirit of the one organization one vote rule, and that I couldn't justify continuing to pay to be on the committee with this behavior. They took it under advisement. Eventually, public review time came around. I submitted a document containing something on the order of 800 comments. These were pretty repetitious because I had to hit the document one request at a time, but the major themes were: o The only really worthwhile thing about X was the distributed extension registration mechanism. All of the input, graphics and other crap should be moved to extension #1. That way, it won't be mandatory in conforming implementations once that stuff was obsolete. As you probably know, that's where we are today; nobody uses that stuff but it's like the corner of an Intel chip that implements the original instruction set. As an aside, I upset many when working on OpenDoc for Apple and saying the same thing there. o The atom/property mechanism allows clients to allocate memory in the server that can never be freed. Some way to free memory needs to be added. o The bit encodings should be part of a separate language binding, not part of the functional description. I received a reply from the committee that said "Thank you for you comments." I wrote the ANSI Secretariet and asked "Don't the rules for milestone 9 say that the technical committee must make all reasonable efforts to accomodate public review comments?" The Secretariet wrote the committee. Everybody on the committee from companies such as Sun who had bee prohibited from voting no for technical reasons all jumped up and cried "procedural violation" and voted against forwarding the standard. Scheifler stormed out. I heard later than Scheifler wrote an angry letter to the Secretariet saying "how dare you listen to that one lone consultant when I have the backing of all of these major companies?" The response was "Didn't you read our rules before joining?" Of course, by the time all of this settled out X was entrenched setting back the state of UNIX UI for a long time. A couple of decades ago I bough a Sun Ultra-60 and asked whether it was worth paying for the dual processor version. The answer that I got was "Yes. You need one processor to run X and another for everything else." Wrapping this up, I have a section in the book that I'm writing where I talk about how to design a good API. I pose the question of why none of the original Apple Mac API published in 1985 taking about 1,200 pages is in use today whereas almost all of the UNIX V6 API published in 1975 taking 321 pages is still in use and has been copied by many other systems. I'm sure that everyone on this list knows the answer. X suffers from the same problems as the original Mac API. Scheifler et. al. didn't really do any system level design and modelling. I know this because I discussed it with Scheifler at an ANSI meeting in Tulsa, the only place that I have travelled to on business that had no redeeming qualities. He said "I don't believe in models because they predispose the implementation." Had he done some real design work and looked at what others were doing he might have realized that at its core, X was a distributed database system in which operations on some of the databases have visual side-effects. I forget the exact number, but X includes around 20 different databases: atoms, properties, contexts, selections, keymaps, etc. each with their own set of API calls. As a result, the X API is wide and shallow like the Mac, and full of interesting race conditions to boot. The whole thing could have been done with less than a dozen API calls. Wrapping this up on a happy note, some years ago I was hanging out yakking at the Hacker's Conference when this guy I didn't recognize due to hair loss came up to me and said "I'm not going to say that you weren't an asshole because you were, but you were right." It was Keith Packard who was trying to get X running on the OLPC and had run into the issue of clients allocating server memory that couldn't be freed. Been good friends since. Same with Gettys. Well, that's the whole sordid take from my point of view. Hope that you enjoyed it. Jon

Larry McVoy writes: Well, just to nitpick, I remember that much of SunView was a library but it relied on special device drivers with complicated ioctls and such. I don't recall that it be easily separated from the OS. BTW, on a historically amusing note, I still have two old Sun machines in the basement, a SparcStation 20 and an Ultra-60. The 20 has whatever graphics card supported double-buffering. It has a modified kernel thanks to some unnamed (and unremembered at this point) soul who provided source code. I hacked it so that SunView ran in one of the buffers and X ran in the other. Moving the mouse off of the edge of the screen switched which buffer was displayed. My answer to being able to run both SunView and X. I live in Oregon, about 50 miles southwest of Portland. I will probably be in San Francisco the first full weekend of October for the Hardly Strictly Bluegrass Festival if you're in the bay area. Will be staying at Sun employee #5's house. Jon

Jon Steinhart &lt;jon(a)fourwinds.com&gt; writes: When I was doing my PhD a few years ago, one of the case studies I used was an X11 server that was written in occam 2 by Colin Willcock at the University of Kent at Canterbury. I managed to recover Colin's source code for the X server (in Transputer Development System format), which is dated November 1988, from a very dusty machine backup... I also found the sources for Colin's 1991 report to the funding body on the completion of the project, and his 1992 PhD thesis which describes the same work. I rebuilt these in 2010 using a modern version of TeX, so the appearance is probably different from what Colin intended (and the cover-page dates are definitely wrong), but they're quite readable: https://stuff.offog.org/cw3-report-rebuilt.pdf https://stuff.offog.org/cw3-thesis-rebuilt.pdf Note in particular the motivation stated in the report: "The worst of these problems was the MEiKO C compiler, which (by mid-1988) proved incapable of making any significant headway when presented with the public-domain X-sources. [...] After consultation with the project monitoring officers at RAL, we took the decision to investigate the prospects for a complete re-implementation of the X-server in occam 2, making no use of the public domain C sources." There have of course been other X server implementations more recently, but they're less historically interesting! -- Adam Sampson &lt;ats(a)offog.org&gt; <http://offog.org/>

On 09/13/17 02:14, Jon Steinhart wrote: Ever since I got in contact with X11 (around 92/93 with my first Linux and 386BSD installations), I was wondering what happened to the previous versions. You mention X10. Is there any documentation of source code of it available? And what about X1 to X9? regards, chris

On 13 September 2017 at 15:10, Kurt H Maier &lt;khm(a)sciops.net&gt; wrote: Full X10R3 and R4 source is still on x.org: ftp://ftp.x.org/pub/X10R3/ ftp://ftp.x.org/pub/X10R4/ -Henry

Is the forerunner of X, I think called W? still around somewhere in source-form?

Hello! Wasn't the original project called "Athena", and wasn't it pursued by one of the many Labs at MIT? I remember going over it in a big way about the same time I started being an almost serious kernel hacker, and that was while the kernel created by Linus was using BitKeeper as its source control mechanism. This was around the turn of the century. Oddly enough I also pursued and engaged a company who attempted to combine an early X release with thier DOS based multitasking tool. The discussion was rewarding, but it did not save the company. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again." On Tue, Sep 19, 2017 at 10:05 AM, Jon Steinhart &lt;jon(a)fourwinds.com&gt; wrote:

On 19 September 2017 at 11:39, Chet Ramey &lt;chet.ramey(a)case.edu&gt; wrote: I vaguely recall (assuming no bit rot) that IBM was also involved and they refused to release their portion under FRAND terms, leading Bob to write X. Anecodotes on W/X may be found in the delightful little book written by Borenstein titled "Programming as if people mattered". N.

On 9/19/17 2:23 PM, Nemo wrote: As I understand it, Scheifler began with W, which Paul Asente and Chris Kent had ported to Unix and given him a copy. He initially replaced its synchronous protocol with an asynchronous one and went on from there. I don't know whether IBM was involved with the V OS research, which was where W came from, or resisted its public release, but Scheifler certainly got a copy. Jon Steinhart covered a little bit of this in a message to this list last week. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/

On 9/19/17 2:32 PM, Chet Ramey wrote: This is covered in one of the original Athena papers: The X Window System by Scheifler and Gettys. I have the full set of "Project Athena: The First Ten Years"; it's in volume 1. I think that paper was presented at a couple of conferences, so there are probably copies floating around on the net somewhere. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/

On Tue, Sep 19, 2017 at 11:16 AM, Gregg Levine &lt;gregg.drwho8(a)gmail.com&gt; wrote: ​Greg - not quite right, although I can see how I might look that way from the outside. The Athena project was MIT's reaction to the CMU Andrew​ Project. I'll not bring the somewhat humorous history but basic question asked was simple... assume CMU succeeded in building the proposed 3M 'SPICE' system for Andrew. MIT wanted to know: How would you deploy it? Athena set out to figure that out... It's interesting the two pieces of Athena that actually still live are X and Kerberos where were developed as part of the Athena project. I understand why Kerberos and much of that tech was needed if you were going to deploy hundreds of computers. I don't remember the argument for writing X - i.e. why it was needed, you'd have to ask Dan Geer (I've forgotten). FYI: In the case of Andrew, Mach and some of the AFS technology (and I've heard some suggest it helped to move IBM into the doing RIOS which eventually lead to Power/PC). Clem

Hello! Spot on. I've used it, and attempted to get it to work. Annoying thing it is, is that it only sees Novell's IPX based networking. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again." On Tue, Sep 19, 2017 at 1:01 PM, Steve Nickolas &lt;usotsuki(a)buric.co&gt; wrote:

On 9/19/2017 2:56 PM, Derek Fawcus wrote: http://www.cs.cmu.edu/afs/cs.cmu.edu/project/phrensy/pub/www/dvx/faq.txt To communicate with Unix machines, you must have a TCP/IP protocol stack that DESQview/X can communicate with. The following products are compatible: FTP's PCTCP HP/Lanman TCP/IP Novell's Lan Workplace for DOS PathWay Access (from The Wollongong Group Inc.) BW-TCP and BW-NFS (from Beame & Whiteside Software Ltd.) PC-NFS (from Sun Microsystems) I remember playing around with it a long time ago - I think I used PC-NFS with it.

On 19 September 2017 at 13:01, Steve Nickolas &lt;usotsuki(a)buric.co&gt; wrote: I used it but it still sat on top of DOS. I downloaded their GCC-based development tools and tried to build something for X (from X.org). I invoked the makefile and then went to finish laying subflooring in my living room, only to hear the PC rebooting in the other room. It turned out that many of the header-file names were identical in the first 8 characters. This led to recursive inclusion until it blew. N.

On 09/19/2017 05:40 PM, Wesley Parish wrote: I ran across DeskView in the mid '90s too. I occasionally thought about how it did graphics in MS-DOS but never really thought that much about it. Since learning about DeskView's X11 (or 10?) server in the last few months, I'd like to get my hands on a copy to play with. You know, for giggles. -- Grant. . . . unix || die

Unix still needs a decent graphics API (ideally one that can work over a network). Any thoughts on that?

On Tue, Sep 12, 2017 at 6:52 PM, ron minnich &lt;rminnich(a)gmail.com&gt; wrote: I still use them all the time... But maybe I'm a nobody... Warner

On Tue, Sep 12, 2017 at 6:56 PM, ron minnich &lt;rminnich(a)gmail.com&gt; wrote: VNC to the phone is the best thing ever... But I like a real keyboard... Warner

On Tue, Sep 12, 2017 at 7:06 PM Kurt H Maier &lt;khm(a)sciops.net&gt; wrote: I don't disagree. I just think the knowledge of all that is lost, the same way so much knowledge of unix is lost. That's why we have things like systemd. ron

On 9/12/2017 11:55 PM, Jon Steinhart wrote: Completely agree. To keep beating the dead horse, in high school we had access to a PDP-10, a KA10 running TOPS-10 5.06 - later they switched to 4 KS10s running TOPS-10 6.03 I gained some notoriety as a hacker, and was tasked by the consulting firm that ran the things to build a "better" MIC (a batch scripting tool that allowed you to run things offline and go back later to look at the results). I had exploited the original DEC version to give me access to [1,2] ;) Anyway, during that period, I was allowed to visit the installation, and if it was a weekend when students weren't on, to mount the "black" RP06 pack that had all the TOPS-10 sources on it, and look at or print out anything I wanted (look or print, same thing, really, the access was via LA120). I learned a lot. Went on to work for the place for a few years. Somewhere during that time, I was exposed to the IBM-PC and PCDOS. Except for my own projects in assembler, the IBM DOS and Technical Reference Manuals were all I had access to. HOWEVER - IBM in their infinite wisdom actually provided the sources to the BIOS in the manual. Still have that manual. That was awesome. I didn't have the DOS sources, but it wasn't hard to disassemble them with DEBUG and take a peak anyway. Back then, it was all written in assembler anyway, so it was only missing the symbols. Nothing was "out of reach". Now, with C or C++, or worse, higher-level languages being the default choices, that optimize everything to death, it's hard to disassemble anything and really "see" what it's trying to accomplish, and how. Not impossible, I've done some reverse engineering of various OS's, but nothing spectacular. For today's kids, well, it's a much different story. My son has a CS degree, but has almost no experience really peaking under the hood of any OS - some small ventures into kernels, but nothing huge like UNIX. Which brings me to another thing. Linux sources are freely available, and yet I don't see anyone really looking at them as an educational thing. I might be wrong, my experience in higher education is NONE.

Try installing Oracle products on UNIX/Linux without X. Better yet, try doing it on a remote machine on the other side of the world. While KVMs like a Dell DRAC or Sun LOM, and virtualization consoles help a lot, it's nice to be able to "ssh -X" to a remote machine and run that installer back to my local VNC server. If I had a decent X windows implementation locally, I'd use that instead of VNC. X had it's issues. But it's still alive and well - maybe because of Java ;) On 9/12/2017 8:52 PM, ron minnich wrote:

Well I do. I’ve been looking at gigantic simulator trace files recently, and the graphics is far smaller than the underlying data. -L

Heavy number crunching generating some data for display may be far from the one displaying the data. [sensor input | storage] => [computation} <=> [display/user input] ... Indeed. The question really is where in the pipeline from gobs of raw data to number crunching transformations to display does the network split lie. In a sense we already have a split (GPU vs CPU) but it is highly specialized. Camera, mouse, graphics tablet, keyboard, other sensor inputs will be (or should be) near the display but may be processed far away in an application specific manner. I suspect here too we may go through Sutherland's wheel of reincarnation. We can offload more GUI processing in the server but as GUI becomes more sophisticated (or complicated), it will feel slow. I can envision using a RaspberryPi as a "graphics processor" but we still need a protocol between the 'Pi and the "backend". If done right, I wouldn't want to touch the innards of the s/w running on the 'Pi when writing a game or something needing visualization.

Grant Taylor writes: Well, I agree that this is one area in which X does OK. Although, being a command line sort of guy, I'm happy to ssh into a machine and run commands. I try to avoid non-scriptable GUIs. I don't administer headless machines, and stay very far away from Oracle. I'm not sure what their installer does, but usually running X requires an installed and running system. So since a number of people have justified networked graphics we're back to the question of what an API should look like. At a very high level, it needs to be modular because there is no one thing that gets done with graphics, and there's no reason to carry a huge API around just because you need a small part of it. In particular, there is a distinction between applications that spit out geometry and those that spit out mass quantities of pixel/voxel data. Also, because of the way that this discussion started, I'm not sure whether or not resource management (windows, keyboard, etc.) falls under the umbrella of graphics. Jon

Grant Taylor writes: I'll save you the trouble. 3D. Volume equivalent of a pixel.

Tony Finch writes: Not that I'm aware of. The main difference was in the name; Display Postscipt just displayed Postscript; it's what NeXT used for higher quality rendering. NeWS was a window management system that included Postscript graphics.

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" &lt;jon(a)fourwinds.com&gt; To:<tuhs@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(a)skeeve.com writes: into thing. never took design, 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. for 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(a)ronnatalie.com writes: proponent Sun 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

On 12/09/2017, Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote (in part): 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.

On Wed, Sep 13, 2017 at 08:53:07PM -0400, Nemo wrote: I tend to just use Debian and Debian derived releases and stuff works for me.

Rico Pajarola &lt;rp(a)servium.ch&gt; wrote: Libtool for sure. Autoconf is something you have to come to a negotiated truce with and then it's OK. :-) 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

On 9/14/17 8:13 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. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/

On 9/14/17 9:27 AM, Rico Pajarola wrote: I have 1.05; it's the oldest version I have ever found. 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(a)case.edu http://cnswww.cns.cwru.edu/~chet/

Definitely getting off-topic here ... Steffen Nurpmeso &lt;steffen(a)sdaoden.eu&gt; wrote: 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. 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. Much of it is probably obsolete. Some things date back to the days when some systems had strchr() and others had index()... 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. No arguments there, but unfortunately, Plan 9 is a very self-contained sandbox. Few of us get to live there all the time. Arnold

Autoconf didn't originate with Gnu. It was around longer than that (someone can probably remember, but I remember some of the netnews software using it long before RMS or LINUX got going). I always havd a lot of distatste for it. I worked on portable software as well, everything form Unipress EMACS to BRL CAD to my own software products (we ran on, let me see if I can recall: SUN both Solaris and the old SunOS4, Stellar, Ardent, HP (both architectures), Apollo, SGI (various levels), DEC MIPS, DEC ALPHA, RS6000, iTanium, i8t0 (several flavors), the 80x86 in many flavors, Intergraph 32032, Intergraph Clipper... We were always able to disttill the portability information into a single set of include files, one conf.h and one included for each platform. Most of the grief came from people with various ideas on how to do 64 bit seeks and of all things (thankfully we got away from this) stty/ioctl. I never had to resort to a script to set things up. Reading down through conf.h told me what my options were and it didn't take long to set things up. I also ported/wrote X11 servers for four or five systems (including writing my own CFB24 before MIT released theres). iMake worked pretty well, though since it relied on the C prepropcessor and the exacxt format of the C preprocessor output really isn't defined for white space, it sometimes was a problem. Eventually, we picked up CMAKE though I don't particularly like that one either.

Years ago, I was building an RSX-11M system and it had a rather intricate setup script. At one point it announced: "This will take a while. Go have a cup of coffee." And I useually did. Then one day I was building a machine in another lab and it said: "This will take a while. Go have a cup of tea." OK, I had to dig into the script to figure it out. Turns out the beverage selection was dependent on the configured line frequency. The lab system was built for European deployment (50HZ power).

On Thu, Sep 14, 2017 at 02:00:05PM -0700, Chris Torek wrote: Heh, I remember that :) And I ran on Eunice back in the day.

On Fri, 15 Sep 2017, Larry McVoy wrote: I resemble that remark :-) I used to tell a boss that Eunice made VMS look civilised, and he growled back "No, it makes it look like Unix." But that's what I said :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

On Sep 14, 2017, at 1:22 PM, Jon Steinhart &lt;jon(a)fourwinds.com&gt; wrote: My days of wrestling with libtool/autoconf/automake/cmake are mostly in the past. On FreeBSD/MacOS I use pkg/brew. For any new coding I mainly use Go. Even cross compiled binaries just work. It has a very well engineered ecosystem. I agree with this. auto{conf,make}/configure is just the wrong approach. At Real Networks our media server ran on 12 or so Unix platforms + windows + macOS9 (at the time). I managed to corral machine dependent code in basically a couple files for all but MacOS9. No #ifdefs in any other file. C++ also helped to hide things like select(2) vs poll(2) from other code.

arnold(a)skeeve.com wrote: |Definitely getting off-topic here ... Do not think so, my i386 had a 20 MB hard disc... |Steffen Nurpmeso &lt;steffen(a)sdaoden.eu&gt; 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)

On Wed, 13 Sep 2017, Nemo wrote: 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."

The command MAKE on TOPS10 was an interface to the editor (TECO). . MAKE LOVE NOT WAR? [4K CORE]

Dave Horsfall &lt;dave(a)horsfall.org&gt; 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@wales tmp]$ smake love smake: Can't find any source for 'love'. smake: Couldn't make 'love'. ?1[steffen@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)

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" &lt;scj(a)yaccman.com&gt; wrote:

On Wed, 13 Sep 2017, Larry McVoy wrote: 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."

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: -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

On Thu, 14 Sep 2017, Steve Johnson 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. -uso.

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 :( .

"Ron Natalie" writes: 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".

On Mon, Sep 18, 2017 at 08:52:08PM -0400, Random832 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.

On Mon, Sep 18, 2017 at 10:56:51PM -0400, Gregg Levine wrote: 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

On 2017-09-18 19:50, Larry McVoy wrote: 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.

Larry McVoy &lt;lm(a)mcvoy.com&gt; 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)

On Tue, Sep 19, 2017, at 09:56, Larry McVoy wrote: 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.

On Tue, Sep 19, 2017 at 08:31:52PM +0200, Steffen Nurpmeso wrote: Feel free to send in a patch!

On Tue, Sep 19, 2017 at 01:56:48PM -0400, Random832 wrote: 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?

On Mon, Sep 18, 2017 at 10:50 PM, Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: ​+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

On Tue, Sep 19, 2017 at 10:42 AM, Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: ​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."​

On 2017-09-14 09:22, Dave Horsfall wrote: Maybe some are deluded like that. But the more typical case (and I saw this personally not just on "the Internet") are those who actively and consciously disdain Unix, and want Penguin kernel based systems to move to a completely new and different userland, free from any links to Unix history. And we should stop assuming they're kidding when they say so openly. -- 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.

On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote: It's mostly Lennart Poettering and his fan club, but it's also important to remember that Unix was not perfect. For years, I've been ranting about the telldir/seekdir interface, for which JFS has three b-trees that have to be updated for every directory operation --- one of which was added *just* because of telldir/seekdir. Other file systems make other design choices or go through other bits of hell just because of telldir/seekdir, but assuming a 32-bit cookie which must survive potentially indefinitely, with the readdir "will return file names exactly zero or one times" guarantees required by POSIX, is rather hellish. Or, say the atime update requirement, which can be a performance killer, and for which the default on Linux violates Posix, and so I suppose it technically isn't allowed to use the Unix trademark anyway. I'm sure the Plan 9 folks could come up with other Unix shortcomings. :-) - Ted

On 09/14/17 21:52, Steve Nickolas wrote: I, too, was toying with the idea of creating a NetBSD distribution which uses the Linux kernel and NetBSD userland. I very much like the concept of going to /usr/src and typing "make build" (or "make world" on FreeBSD) and have the whole base system rebuilt. I've played with Gentoo Linux which also builds from source, but I found it too complicated (for me, at least). On the BSDs it's just Makefiles, and no strange python (or whatever) scripts to build the system. Maybe when I'm retired and have plenty of time... regards, chris

The u-root project (u-root.tk) is aimed at creating the *nix tools in Go. The targets are firmware where linux and an initramfs are loaded; and root file systems. One goal was to get back to old school unix where the root always included the source to create the commands. In the non-firmware mode all the sources are there and they are compiled on demand, save for the 4 go tooclhain binaries and /init. It takes about 15 seconds to compile all the tools at present. We've got a demo OS for Chromebooks based on u-root called NiChrome (NiChrome is an alloy of Chrome). This was a summer project for 2 interns here. It helped show that the idea can work to support an OS distro. We've also shown that linux and a u-root initramfs can replace most of UEFI firmware on the Open Compute Platform nodes, reducing boot time from 8 minutes to 17 seconds. Not as fast as the 3 seconds I'd like but you gotta start somewhere, and most of that time is beyond our control. We can always use help if you're interested. I'm ok with C for kernels but don't want to use it again in user mode, hence this project. ron On Thu, Sep 14, 2017 at 3:39 PM Erik Berls &lt;erik(a)ono-sendai.com&gt; wrote:

You can do better than your old-school Unix experience with a pi and linux :-) On the 1st gen RasPi the linux kernel took 10+ hours to build from scratch. In contrast the plan9 kernel took one minute. The equivalent of FreeBSD's "make world" for plan9 took 4 minutes. IIRC half of it was for ghostscript.

Forget ports! /usr/src is bad enough. Running buildworld, it takes longer to build the flippin' compilers (llvm) than it does to build the entire rest of the OS. This is not progress. --lyndon

Common thread: LLVM is written in C++. (Also, at some point during compilation, at least some versions grow quite big, using 20 GB of RAM or whatever. And C++ is hard on the linkers as well...) Chris

On Thu, Sep 14, 2017 at 4:06 PM Bakul Shah &lt;bakul(a)bitblocks.com&gt; wrote: whatever go runs on, u-root will run on, but there are places we had to use Linux-specific stuff (e.g. netlink) that you'd have to write code for or you won't get thinks like the ip command or dhcp client, and so on.

Kurt H Maier writes: Well, I'd suggest that a lot of this has to do with people who have vision and people who don't. When you look at UNIX, you see something created by a bunch of very talented people who had a reasonably shared vision of what they were trying to achieve. I happen to be good friends with John Gilmore, and early Sun employee and one of the founders of Cygnus Solutions which one can argue did more for the acceptance of open source than anything else. Whenever we get into an argument (which is really easy to do with John) over how to do something he falls back onto "When I was a Cygnus and wrote GNU tar..." I always point out that implementing something that was already defined was way easier than defining something new, and a completely different skill set. So I would make the claim that Pottering et. al. are not good definers, and their model for definition comes from Microsoft which is also not a good definer. Along these lines, I think that the demise of UNIX began with AT&T/USL for the reasons above. I would much rather use UNIX Version III than UNIX System III. Jon

Frankly, I don't give a hoot about what the FSF or especially RMS cares about. RMS used to show up at my house on a regular basis, and I spent time in the early FSF with some of the people I really respected other than RMS (like Len Tower). RMS while condemning everybody else, cares little about other than himself and his sociopathically depraved views of the way the world should be. And as Forrest Gump would say "Tha'ts all I have to say about that."

On Thu, Sep 14, 2017 at 05:35:35PM -0400, Theodore Ts'o wrote: As well it should be. My colors are showing here, but I'm really sick of the FSF slapping their name on other people's work. If Stallman wants it to be called GNU/Linux let him write a kernel. He didn't, he can't, yet he wants credit. I got pretty disgusted back in the day when everything that was GPLed suddenly became a GNU project. The GNU guys have written very, very little code. They are all about the license, which is fine, but I get off the bus when they are claiming credit for work they did not do.

RMS hates UNIX. That was clear in the original manifesto. But he's also a megalomaniac and believes that if you even use a GNU tool your work becomes his.

On 9/16/17 8:59 AM, Ron Natalie wrote: Nah, this is BS. Stallman might not like Unix, and he clearly has a very large ego -- as do many of us here -- but that "belief" is just crap. The thing that comes closest to it is bison, and the output of bison is explicitly excluded. There is the issue of GPL libraries (like readline), and that's a pain for people who want to link with them, but that doesn't count as "even use a GNU tool." -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/

Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: Um, let's see: Bash. gawk. sed. grep. coreutils. binutils. gcc. ... Essentially everything that was used from the command line on a standard Unix system. All reimplemented from scratch. Many GNU maintainers are active (directly or indirectly) in the POSIX standard efforts which influences all Unix implementations. This not true of ALL the GNU project maintainers. Don't tar everyone with RMS's brush. 'nuff said, And, IMHO, all this is WAY off topic and probably should be brought to a close. Arnold

On Sat, Sep 16, 2017 at 01:20:00PM -0600, arnold(a)skeeve.com wrote: What are we supposed to to then? cpio?

On Sat, Sep 16, 2017 at 08:14:47PM -0600, Warner Losh wrote: I think you missed Jon's joke. If you want more of that, check out this thread: https://www.reddit.com/r/IAmA/comments/70arwl/i_am_john_cleese_writer_actor…

On 2017-09-16 18:55, Jon Steinhart wrote: pax posixana! -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. Do obvious transformation on domain to reply privately _only_ on Usenet.

On 9/17/17 1:19 AM, arnold(a)skeeve.com wrote: I remember multiple FSF efforts to solicit volunteers for named projects. There were lots of people willing to donate their time and effort. And at that time, there were very few non-FSF projects licensed under the GPL, so the issue of "absorbtion" was minor to non-existent. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/

On Sun, Sep 17, 2017 at 12:57 PM, Kurt H Maier &lt;khm(a)sciops.net&gt; wrote: FreeBSD started out life with lots of GNU/GPL software. After GPLv3 was released, the project made a conscious effort to move away from all GPL'd software in the tree. When FreeBSD 12 comes out next year, there's a really good chance all the GPL'd code will be gone from the tree. Fun times, that.... Yea... Warner

On 9/17/17 2:57 PM, Kurt H Maier wrote: This is all true, though I would argue that the "copyright assignment to the FSF" was there from the beginning, and concealed by the fact that the early work was directly funded by the FSF before being handed off. Certainly they asked me for a copyright assignment early on, and this is almost 30 years ago. There just weren't that many objections. I would also argue that the different versions of the license were the result of people asking for exceptions or clarifiations, and the FSF attempting to accommodate them. There's no question that the GNU project is at least as much of a social policy effort as a technology one. You can't leave either one out of any history. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/

On Sun, Sep 17, 2017 at 02:43:33PM -0400, Chet Ramey wrote: OK, let's hit the reset button on this one. I'm happy that the GNU project exists, I benefit from it every day. I am explicitly stating that I appreciate all of the work that people have done as volunteers, I'm one of them. What I'm not a fan of is Stallman getting people to put stuff under the GPL and then acting like he/FSF wrote the code. He still claims credit for GCC to this day and the Stallman GCC was *nothing* like a Ken C compiler, it was junk. Tiemann at Sun and then Cygnus, did the real work to make that thing actually be a reasonable program. Don't believe me? Go find a pre-Tiemann GCC and try and compile any reasonable program with it. As someone else pointed out, emacs wasn't RMS, it was Gosling. RMS has a track record of starting stuff, hijacking stuff, and claiming credit. That is what I don't like. I like the GNU project just fine, I'm not a fan of people claiming credit for stuff they didn't do. I really soured on on RMS when the FSF took my ls -h/du -h code and "rewrote" it so they would not have to give me credit. That's pretty petty. He did it because he hated me because BitKeeper wasn't open source enough for him and the kernel was using it. So he wanted to scrub the GNU source base of any of my contributions. So I stopped contributing. I'll leave you with a story from the Cygnus days, I was friends with all three founders. I was having dinner with Gumby and Michael and we were discussing RMS. It was RMS this, RMS that. Gumby's wife is German and at one point she says "OMG, you mean RMS!". We say "yeah?" She says all this time I thought you were saying "Our mess". We paused, replayed the conversation, and were sort of stunned that every sentence made sense with "our mess".

On 9/15/17 11:40 PM, Larry McVoy wrote: You are associating not having a lot of paid employees with not having a lot of people do work under the FSF banner. That's not close to true. It's true that the FSF had few full-time employees. They worked off grants. It's not true that these folks didn't produce a lot of work: they did. It's true that the volunteers who donated their work to the FSF did so fully understanding what they were doing. Arnold and I have first-hand experience here. It's true that there were a number of projects that petitioned to come under the FSF umbrella, and were accepted. It's not true that everything released under the GPL became part of the GNU project and was listed on www.gnu.org/software. I get that you don't like the FSF model, but the organization and its volunteers produced -- and continue to produce -- a significant body of good work. Linux as people think of it today (no, it's not just a kernel) really wouldn't exist without it. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/