Greg 'groggy' Lehey scripsit: Sure, go ahead. As a firm adherent to "ex", I'll umpire the contest. -- "Well, I'm back." --Sam John Cowan <cowan(a)ccil.org>

On Sunday, 1 June 2014 at 23:37:46 -0400, John Cowan wrote: :-) Greg -- Sent from my desktop computer. Finger grog(a)FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua

Yeah. I think Richard Stallman is a legend (umm if that's too close to "awesome" vocabulary wise then let's say he's an inspiration :) :) ), I totally agree with everything he's done for & on behalf of free software and really it's easy to forget how totally locked out of the unix world I was as a 10yr old MS Basic programming hobbyist or 20yr old MS Basic programming developer, never even used an SCCS until I was nearly 30. My professional life would have been way more productive and satisfying if Stallman had come along much earlier... I knew people who used unix and packet-switched networks such as X.25 but being run for profit by large corporations it was totally out of my price range. I also remember how much I just yearned to have the source code of MS DOS, CP/M, AppleSoft & DOS 3.3, etc, so many unanswered questions that were only partially alleviated by books such as "Undocumented DOS" and "Beneath Apple DOS"... I did eventually get some of those sources or a version of them when it was much too late & was disappointed to see how mediocre they looked from developer's viewpoint... community could have dome much better but were locked out of the process & relegated to writing apps & device drivers that took ages to get working in light of limited technical info. I'll never be in that situation again thanks to Stallman's insights and Torvalds's and everyone else's contribution. I deplore the infighting though and have had bad experiences in trying to offer what little time I could afford to open source projects, now I do not really bother & just use the tools with my own private modifications. I do think Stallman has a point about naming of Linux v. GNU/Linux though. What I do not like about GNU is the "kitchen sink" philosophy of including every little used feature in every utility with longer and longer command line switches and manpages. Bash I guess is an extreme example of this, we do not need a commandline shell that is 1Mb in size!! Another issue I have is the incredibly complex tools such as GCC being written in plain C when some subset of C++ would clearly be more appropriate given their fundamentally object oriented design. This is very laborious, repetitive and wasteful and involves a lot of differing "private solutions" to already-solved problems. Further the build systems are totally broken, I appreciate what automake/autoconf is doing but from a developer point of view they are totally unwieldy and another example of the "kitchen sink" philosophy of supporting every conceivable, and outdated, architecture. Much better solutions exist for these kinds of problems. For these reasons I would likely not work on a GNU project, however I use the tools daily and simply ignore the parts I don't like. If software development were left to me I would be infinitely subroutinized, redesigning the CPU so I could redesign the ISA and then return to redesigning the compiler followed by the OS kernel followed by the C library, the windowing system and the apps hehehe so RMS perceived a need and filled it within a useful timescale and I'm infinitely grateful :) cheers, Nick On 02/06/2014 1:26 PM, "Greg 'groggy' Lehey" <grog(a)lemis.com> wrote:

John Cowan <cowan(a)mercury.ccil.org> wrote: This is only possible because of the standardization efforts at the C and POSIX levels. Remember that Autoconf/Automake were invented to solve the issue of all the forks: SunOS / Solaris / HP-UX / Ultrix / MIPS / Pryamid / DG-UX / ad nauseum. Lots of things that were almost but not quite entirely like V7 or System V Unix. Today many of those players are no longer around, AND standardization of header files and libraries means that C code is *more* portable than it was in 1992. So there's less need for those tools *now*, but that doesn't mean they didn't solve a real problem when they first came along. I'll agree on most of the GNU complaints (and I'm a GNU developer...); the original Unix "Small Is Beautiful" baby has been thrown out along with the proprietary licensing bath water. Sigh. (Boy, was that a great use for an old cliche, or what? :-) Thanks, Arnold

On Jun 2, 2014, at 11:35 AM, John Cowan <cowan(a)mercury.ccil.org> wrote: Sounds a bit like imake-uberlite… Or should I not mention imake lest the love-fest for all things evil continue on it. :) Warner

Warner Losh scripsit: And a Good Thing Too. Public squabbling about trivia serves no one's interest except the enemies'. Much less buggy and more Posix-compliant, I think you mean. (The .sig below was chosen at random and in advance, but it's fitting.) -- John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org We are lost, lost. No name, no business, no Precious, nothing. Only empty. Only hungry: yes, we are hungry. A few little fishes, nassty bony little fishes, for a poor creature, and they say death. So wise they are; so just, so very just. --Gollum

On Mon, Jun 2, 2014 at 8:27 AM, Ronald Natalie <ron(a)ronnatalie.com> wrote: ​Ron you are right.. A number of us used dmr's compiler much less Steve's compiler to "port UNIX" to a lot of different things (some where good and some not so good - my own attempt at retargeting the V7 Rtichie compiler to yet to be name processed experimental process from Moto (later called the 68000) proved "good enough" for the Magnolia project at Tek but it was not really not a very good compiler). But you had to have an AT&T license to get it. Admittedly a lot of universities did and that did certainly cause C to get a huge foot hold over its contemporaries (say BCPL, BLISS and maybe PL/360). IMHO: what rms did was put a production quality compiler into play that had sources, that anyone could use and anyone could hack on without having to purchase it or need some sort of license other than his GPL. At the time, there had been lots of attempts at different compilers both "free" and commercial - some with sources some not (I fondly remember Ron Cain's Small C for the 8080 being pushed in Byte Magazine the late 1970s/early 1980)​. Even Whitesmith's (Plauger's) compiler was really not what would we have called production code quality. gcc was not (still is not) perfect and compared to a number of commercial compilers -- say something like the current Intel compiler or the old DEC, Masscomp or Sun compilers. But the "gcc family" did prove to be fairly easy move to a lot of UNIX/UNIX-like and non-UNIX OS platforms, at the same time able to be retarget to a number of different ISAs, even a number of different front ends; all while generally creating good/reasonable if not darned good/close to optimal code (at least for many of the targets were the most popular/that mattered). Frankly, we have seen few developer suites that have been as lasting and I might suggest that until the LLVM project there has been few (none) that have had a chance of being so [Tannebaum's compiler kit maybe - but I never same that it never really went anywhere]. My observation is that without a "pretty good" compiler that was reasonably "universal" the rest of the command suite would have languished/not happened. As Doug points out the base OS really never happened from rms (they had Trix, then the Hurd and finally defaulted to Linux). But the command suite was able to grow and lots of people besides rms contribute to it, because the basic development tools were there. As strange and difficult a person he is, I suspect we do all own rms a certain level of thanks for the basic dev tools. Clem

Tim - cart and horse reversed.. ;-) Linus did not like the fact the when Andy wrote Minux, he and his students did not use the 386 MMU HW. It was made to run on a 8086/8088 -- straight PC/XT because Andy wanted the lowest cost of entry for his students. Also at the time, Andy's compiler tool kit was not as easy to get the source. My memory on this part is hazy, but I think you had to purchase the compiler sources. So Linus started with MINUX and started to add more and more support. He eventually tossed out the ukernel nature of Minux and went the more traditional kernel architecture. He and Andy would famously fight about that choice on usenet. Linus this would eventually need a compiler and pulled rms' suite. The funny part is that his University has 386BSD (aka 4.2 for the 386) at the time which did use the MMU, had networking and even the first step at X11. At the time I had helped the guys get the AT disk driver working as I had access to all the Western Digital documentation. But to get the code from CRSG, you needed at BSD license, which required an AT&T license. Linus' university had one, but he did know know the magic ftp site to download or have access. I've often wondered what would have happened if he had known about it. And again, fast forward about 18-24 months and folks like me were worried when the BSDi case came out that we were going to lose access to a UNIX for the Intel processor. So we started to help him, even though at the time is a huge step backwards. Clearly, the "powers" at AT&T really did not know they were awaking a sleeping animal in the hacker community. Clem On Mon, Jun 2, 2014 at 10:11 AM, Tim Bradshaw <tfb(a)tfeb.org> wrote:

And, to think, I thought operating system wars and editor religions had died long ago.... aps. Begin forwarded message:

On Mon, Jun 2, 2014 at 2:27 PM, Brantley Coile <brantley(a)coraid.com> wrote: Perhaps. But nostalgia aside, something I find interesting (and frankly a bit distressing) is what seems to me to simply be an acceptance that it's all going to end with Linux. That is to say, no one ever seems to talk about what will come *after* Linux. Will Linus's kernel truly be the last kernel anyone works on seriously? Somehow I very much doubt that. And yet, you don't see a lot of talk about evolutionary paths beyond Linux; it's a sort of tunnel vision. For a while, it seemed like Plan 9 and/or Inferno could be the way forward, but they seem to be all but dead. What will be the next step forward? - Dan C.

On Jun 2, 2014, at 3:10 PM, arnold(a)skeeve.com wrote: Plan 9 will be my development system for the foreseeable future. I built the PIX on BSDI using all the tools from the Labs that I could get my hands on, such as sam(1), rc(1) (from Byron), mk(1), and 9win. I shifted the group to real Plan 9 in 1995, when it became available. I used it to build Coraid and I’ll use it for any startups in the future. I get more done faster using it than any other system I’ve tried. I have always kept an independent version running and pick and choose what goes into it. For example, I still run a Ken Thompson file server, even after it was replaced with “better” technology. Plan 9’s stability is one of the things I greatly value; some parts of our system have uptime’s longer than two years. In the past few years, Erik Quanstrom has been Coraid's keeper of our version of Plan 9. For me, he still is. He has worked, with others, to keep the drivers current and adjust things to the changes in hardware. We run a 64 version, for example, on the latest Intel hardware. It might have a very tiny user base, but they will pry Plan 9 out of my cold dead fingers. (That’s a Mike O’Dell reference.) So it will remain alive. Post script. If you want a mindblowingly elegant and beautiful system, study the Oberon system from the 1980’s by Niklaus Wirth. It inspired the Plan 9 editor acme(1). I’ve seen nothing that compares to it’s clarity of thought. Interestingly, Ken Thompson and Niklaus Wirth were both students at Berkeley at same time. I wonder if Harry Huskey’s values are reflected in their work. Brantley

On Mon, Jun 2, 2014 at 3:30 PM, John Cowan <cowan(a)mercury.ccil.org> wrote: Forgive me, but I think that's a bit of an odd analogy (or perhaps an indication that I did not adequately explain what I meant). However, let me run with it for a moment and rephrase my statement: there can only be a discovery if one decides it's worth doing the sort of investigation that would lead to a new discovery, and I wonder whether "we" still have that kind of curiosity or drive. Or has Linux become so entrenched that no one can imagine bothering anymore? There will be a new kernel when someone decides, as Linus did, to To whit: it appears that "we" (for some large value of "we") have collectively decided that it's not worth looking for a replacement for Linux. If nothing else, I find that interesting. - Dan C.

You are, of course, free to not find it interesting in the way that I do. :-) On Mon, Jun 2, 2014 at 7:37 PM, John Cowan <cowan(a)mercury.ccil.org> wrote:

On Mon, Jun 2, 2014 at 10:16 PM, John Cowan <cowan(a)mercury.ccil.org> wrote: I'm not asking for any prediction. I'm merely stating that it seems to me that people aren't interested in these sorts of things anymore. I find that interesting (and a little sad). - Dan C.

On Mon, Jun 2, 2014 at 3:47 PM, Chris Nehren <cnehren+tuhs(a)pobox.com> wrote: Well, without knowing me or a thing about me, that's a strong statement. There is a lot of innovation happening in illumos and BSD. [snip] This is my point. s/Linux/(Illumos|.*BSD)/ and the point remains largely the same. These aren't new systems trying out fundamentally new ideas; they're making incremental improvements on things that have come before. That's all well and good (and it's nice to have an alternative to Linux specifically), but building on a nearly 50 year old framework isn't particularly innovative, despite claims to the contrary. Now don't get me wrong, that framework remains wildly useful, and so that work has value, but my question is more generally whether anyone has the kind of drive to come up with the sort of next generation system that Unix represented when Unix was new? Things like Plan 9 and Akaros are more along the lines of what I was thinking of: mentioning *BSD or other such systems reinforces my thesis. - Dan C.

First, let me say how cool it is to be replying to the guy who did yacc. I've used it for decades, thank you for that. I was at SGI when they did the Origin servers, the architecture (as I remember it) was a board with 2 CPUS, some local memory, and an connection to a hypercube style of memory. An interesting aside is that this is where I learned that infinitely large packets in a network are infinitely stupid because you have to buffer a packet if the outgoing port is busy. I used to be a fan of big packets on ethernet, that system taught me that ethernet is just fine. The Origin "network" had ~32 byte packets. Buffering those was "easy". The problem with the lots-of-cpus design is that memory latency goes up. It was OK for local memory, it was not OK for remote memory. Don't get me wrong, SGI did a really great job at it, but when you compare a bunch of networked boxes with the SMP model SGI had, SGI won on jobs that needed shared memory, the bunch of networked boxes kicked ass on everything else. Cross reference: google. Intel's test harness. And a bunch of others. When you are benchmarking against a 10,000 node cluster and the cluster is winning, yeah, you need to rethink what you are doing. I've copied Greg Chesson, you guys should know him, he's ex Bell Labs, he can correct my ramblings, I worked for him at SGI. --lm On Tue, Jun 03, 2014 at 11:48:25AM -0700, scj(a)yaccman.com wrote:

Hey Greg, It's "tuhs" not "tubs" and it stands for The Unix Historical Society so far as I know. Lots of Bell Labs and other folks on the list, it's a fun walk down memory lane, you should join. What started the conversation was someone musing on whether Linux is the end of OS development. Steve was talking about problems that SGI worked on so I wanted to point out that there might be something to mine there. --lm On Tue, Jun 03, 2014 at 08:42:56PM -0700, Greg Chesson wrote: -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

It would be nice if we end up moving towards something with a solid theoretical underpinning.. seL4 comes to mind. I'd be happy to trade off some performance for some security and strongly enforced modularity. There's still lots to be done (sel4 is just a small microkernel (needed: drivers, filesystems, memory subsystems, etc), and there's little point in having a proven microkernel if you don't keep building up strong software on top of that foundation). </increasinglyOffTopic> On Mon, Jun 2, 2014 at 8:52 AM, Dan Cross &lt;crossd(a)gmail.com&gt; wrote: -- Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com

Tim Bradshaw &lt;tfb(a)tfeb.org&gt; wrote: Linus himself has said as much. I can't find the quote, but I'm pretty sure he acknowledges that. Arnold

Ronald Natalie scripsit: The original Mac 128K was a 68000 processor, and IIRC memory protection didn't arrive until the 68020. -- John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org 'Tis the Linux rebellion / Let coders take their place, The Linux-nationale / Shall Microsoft outpace, We can write better programs / Our CPUs won't stall, So raise the penguin banner of / The Linux-nationale. --Greg Baker

On Mon, Jun 2, 2014 at 10:24 AM, John Cowan &lt;cowan(a)mercury.ccil.org&gt; wrote: ​Sort of. Did not arrive to >>Apple<< until the '020 based Mac-II. Les Crudele (one the 68k's designers) tells a great story about this. The original device had a PDP-11 base/limit register MMU as an external chip who's number I forget (and could not do demand paging by itself -- Masscomp and Apollo would use 2 of them and build their own MMU). According to Les, Moto offered to give Apple the MMU chip at a substantial discount (maybe even free) if they would use it for the Mac. But Jobs famously said it was a personal computer and did not need it (remember the Alto's did not have an MMU either). Later, Moto would release the '010 ​which could do demanding paging with help of an external MMU. The Stanford University Network Terminal (aka "SUN" board) could use the '10. I don't think Apple did themselves, but my memory is that the was an after market '010 mod for some of the Macs. At Masscomp, we retrofited the original CPU board to take a '010. In this mode, the 'fixer' 68K and the '010 could run in parallel during a page fault, which was slightly faster. But functionally, to the end user it was the same as two 68K's. I'm not sure if Apollo did a retrofit. Clem

Zitat von Arno Griffioen &lt;arno.griffioen(a)ieee.org&gt;rg>: One "nice" machine, which actually ran Unix on the 68010 was: http://en.wikipedia.org/wiki/AT%26T_Unix_PC

I ported Unix to the 68000 in the early 1980's and I did what I assume AmigoDOS did; getting a page fault for anything but a stack frame access was fatal to the process. In other worlds, no paging-in a process. The problem for paging was handling side effects from auto increment or decrement access modes. If the faulting instruction used one of those modes, the 68000 didn't provide enough information to do what we did on PDP-11's and simulate the faulted instruction. Nor could it automatically restart the instruction, which was done in the 68010. A process had to be loaded completely before being swtch'ed to, just like in 32v. This left only the fault resulting from the stack meeting to grow. To solve for that problem, we solicited help from the compiler. The function prologue of every function would fetch the farthest used word from the frame pointer. In most cases this would do nothing. For a frame that needed more stack allocated, this would cause a page fault. We looked at the instruction at the faulted program counter, verified it was a "grow me" instruction, allocated more core and put the process back on the run queue. The result of the instruction was ignored, so we didn't need to have the kernel restart it or simulate it. This method wasn't original to me. It was common practice at the time. I assume this the technique used by AmigaDOS. Sent from my iPad

On Thu, 5 Jun 2014, Wesley Parish wrote: If you want to re-read the original article: https://archive.org/details/BYTE_Vol_10-08_1985-08_The_Amiga -- Michael Parson Austin, TX KF5LGQ

On Thu, Jun 5, 2014 at 3:31 AM, Arno Griffioen ‪&lt;arno.griffioen(a)ieee.org&gt; wrote: The original 68000 (and 8-bit data bus 68008) did already have the full 32 bit instruction and data support of the complete family, But the original 68000 was actually a 16 bit internal architecture -- is was made with a 16 bit barrel shifter and any 32 bit op took two ticks. Yes, they (fortunately) did define the 32 bit data types and many of the 32 bit operations. There was an argument at the time was it a 16 bit or 32 bit chip and between people implementing compilers - should a C "int" be 16 bits or 32. Since I had hacked the Ritchie PDP-11 compiler for mine, I used 16 bits, while the MIT guys used 32 (I think they were hacking on Steve's if my memory is correct). The advantage of the later was int == ptr and that the time V6 and V7 was definitely pointer "dirty" the worst example being the Bourne shell and how break(2) was implemented. The advantage of the former was it was the natural size of the chip internals and so it made it easier for me to generate "optimal" (well let's just say "better") code plus that's what's Dennis's compiler "knew." Jeff Mogul ended up at Stanford around that time. He and I had a long argument about it when we first met. We each we sure the other was wrong - :-0 Years later when we became colleagues we reminded of the old argument, I think we agreed that other was "right." It was a tough choice and there were good arguments on both sides. BTW: I once asked Les about it during our Stellar time. He said they thought of it as a 16 bit chip - a PDP-11 like system without running into the problem that Cal Data did with "cloning" the 11. Les and team has been using PDP-11's before they joined Moto. But the reality is that UNIX code really wanted int==ptr for a long time [as well as: ptr = 0; *ptr == 0]. That really was not forced to be fixed until Alpha came on the scene and people cleaned up there code. but for MMU use it ​ ​ lacked one critical feature in the fact that it did not push enough page-fault information on the stack to re-start an instruction in case of an (externally ​ ​ signalled) page-fault. True that the original 68000 lacked the instruction restart ability, but the MMU could be made to not need restart. So even if you interfaced external MMU logic then a basic 68000 was still in ​ ​ trouble when a page fault occurred as it could not 'start over' the ​ ​ faulted instruction. As I said this is not completely true - you just never stopped the instruction. The fact is that a 68000 could do VM, but it took a bit of work a external logic. Forest Basket wrote a paper on how to do it and it was actually what both Apollo and Masscomp implemented in this first products. The trick was that the 68000 "CPU" could not complete the instruction when the fault occurred (or as you mentioned - the reason was that bad things happened was because the microcode did not correctly save the internal instruction state). So the "executor" 68000 CPU was sent wait states by the MMU -- in effect forcing it to have a very slow memory read. While it was waiting for the memory to fill, the fault had to be handled by something else. In Masscomp's case (and I believe Apollo also) the "fixer" was another second 68000 that ran in kernel code that handled the fault and refilled the MMU's TLB (or if you we schooled by Digital - the "TB"). At the time Dave Cane and Jeff ??? ( the logic designer sat Masscomp - Jeff's last name now escapes me) had been from the 11/34 and VAX projects previously. They were horrified to have to use a second processor just for memory refills, and spent weeks trying to find a way out but eventually relented to what the SW guys where telling them. As I said, when the '010 came out, Masscomp retrofitted the CPU card to allow the fault to occur and not wait state the CPU. The RTU kernel detected the actual chip being used, and when it was running on a ' 010, would immediately do a task switch on the executor and run some other code, while the fixer handled the fault. I've forgotten now, but my memory is that the fixer always ran out of the cache. BTW: the '010 originally still had VM issues that did not get fixed until the '020. The way Moto handled the fault was to dump the state of the internal microcode to the CPU stack, and when the instruction was restarted, was to suck the state back into the processor. The problem was that as that Moto was updating the microcode in manufacturing not thinking it was an issues for customers a processor with the step logic stepping might have different microcode - which was not a problem for 99% of their customers. However, Masscomp actually made the first dual processor UNIX box - the MC-500/DP which was released about 12 months after the MC-500 (they predated Sequent by about 2-3 years). A couple of months after we started shipping the DP, we started to see a strange failure in the field. The issues was that a fault would occur on one CPU and the kernel would try to restart to the instruction on a different processor, and unless both CPU boards had executor chips from the same manufacturing lot - you had to restart in the same physical chip that took the fault. Because the original RTU DP system was modeled on the Goble Vax, were kernel mode was on one processor at a time and the original DP had a NUMA memory system (the 5000 was SMP with UMA memory). Thus usually, processes tended to get started on one processor and not migrate to the other, but under they could migrate. All the test systems in engineering had matched processors - no problem. But when field service started to swap boards, around at customer sites, bad things started to happen. We had quite the panic figuring out what it was and then forced field service to ensure all CPU cards were matched -- what a pain in the tuckus. With the 5000 when we went full SMP, we screamed at Moto and got them to clean up their act so that what was dumped on the stack could be restarted on any '020 regardless of stepping/microcode etc. Clem