On Mon, May 07, 2018 at 02:53:26PM -0700, Steve Johnson wrote: While true, that's only part of the story. There was also the issue that what users wanted to *do* with computers got more complex. Consider spreadsheets and relational databases --- how do they get implemented in "the Unix way"? There was rdb, but it was a bit of a disaster from a performance perspective and only worked for toy databases. And this wasn't unique to Unix. In the VMS world, ALL-IN-1 offered group scheduling/calendaring and other "office software" features. You *could* implemnt a group scheduling system using sed, awk, grep, cat, and pipelines --- but would you want to? Is that the best way to go about doing things? And on the hardware side, the advent of hot-pluggable hardware devices and much more complex UI devices (sound, video cameras, etc.) that need to be made accessible to the logged-in user sitting in front of a particular console, put a lot more pressure on the simple login and /dev model of historical Unix. So sure, it's easy to criticize "PenguinOS" for departing from the Unix ideal. But what's the alternative? Can the criticis design something better that matches the needs and requirements of the users (who don't like big question marks on dashboards as "user friendly" error reporting) and the realities of modern hardware and modern user interface? And if so, would those critics care to implement it and contribute it under a BSD-style license? (Or some other Open Source License)? After all competing with the user friendliness of GNOME should be that hard --- and it's been getting easier over the years as GNOME cuts feature after feature from their system. :-) - Ted

I'll take a slight different road on this topic. I think we are dealing with the paradox of progress. I don't blame Linux's developers any more than I blame BSDs or anyone else. Really it was hardware progress/Moore's law that changed the rules :-) As much as I wax a bit for the simplicity of the Fifth, Sixth, and Seventh Editions of my youth, the truth is I would not want to try to use them today. My needs are now different and I think the is true for most people also which is why a modern UNIX implementation is different from the original ideas or maybe I should say ideal. That said, a lot of what I did then, ands like Steve, I still do use and many of the 'classic solutions' I find are better for me (*i.e. *troff *vs.* MS-Word) Pike's '*cat -v harmfu*l' paper foretold where we would get. On the PDP-11 with a limited address, a programmer was constrained so you had to keep things simple. The programming model of small simple programs that did one thing well, was easier to 'enforce.' The ideas that formed UNIX make sense, and yoiu could build an extremely power 'system' from simple and small things. At the time, that was almost heretical. But once HW dropped in price and the address space issues relaxed the size of a program that could be written, people did. The cast was out of the bag, and there was no going back. I'm not saying all of the new BSDism of the time were right, but they certainly made many things easier/more approachable for many users and many/most live in modern UNIX definition. I think Ted makes an excellent point, that *BSD and Linux, by their nature of being 'open' and 'available' pushed the code along and that needs to continue to be the high order bit. Open and freely available had a huge positive effect, because many of these new feature (like X-Windows, Networking) were 'useful' and the cost to add them was accessible -- so people added them. But .... slowly the system changed and the *expectations* of the users with them. I admit, I'm torn. I do think Pike was right and many of the new features/frameworks *et al* are pretty lame (useless IMHO) and the simpler/cleaner methods of old, are being ignored. Dave Pressotto and I were talking a week or so ago and Dave made the observation that he's not sure he knows how write a modern program now with all these frameworks, IDEs, *etc* and I completely agree. But that is the old guy in me talking; but I really do want to see progress and the new generation make its mark. I'm sure they will do wonderful things. Bakul's observation of little >>practical<< progress is an interesting one. In many ways I agree, in others I'm not so sure. I think Ted knows that my major gripe with some of the Linux (and Gnu style) community has been a focus on reimplementing things that were already there instead of using what could have been taken from somewhere else such as BSD, or replacing subsystems just because they could without really adding anything (*i.e.* the whole systemd argument). But over all, as much as I respect and think Ken and Dennis did amazing work at the time, I do tend to love when new ideas/things have been done beyond the original ideas from Ken and Dennis. For instance, just as BSD can take credit (or blame) or sockets and making UNIX really a 'networked OS', Sun really gave us multiple file systems with the VFS, but I strongly credit Linux for really making kernel modules a reality (yup Solaris had them, as did a few other systems - but it was really Linux that made it wide spread). I wish Linux had taken the idea of a modular kernel a tad farther, and picked up things like Locus vproc work, because I personally think modularity under the covers is better than the containers mess we have today (and I agree with Tannenbaum that uKernel's make more sense to me in the long run - even if they do cost something in speed). it's also why I liked Plan 9 and have high hopes that a new OS, maybe written is something like Rust might finally appear. But I don't want it re-implement UNIX or Linux. Grab from them the subsystems that you need to duplication, but don't re-invent. Warren - at the risk of being political -- I think the paradox we have it larger than just UNIX, although it is simple. We can wallow and say everything is bad, it was simpler in 1959 -- which exactly what some folks in my country seem to be doing in other areas. I personally can say my world was simple in those days and I certainly have fond memories [read Bill Bryson's https://www.amazon.com/Life-Times-Thunderbolt-Kid-Memoir/dp/0767919378 which parrots many of my own memories of those times ], but UNIX, like the world, has grown up and changed and is a lot more complicated. I like progress we have now. I don't want the world the way it was any more than I want run Fifth Edition on my Mac for day-2-day work. Yes, I would like us to look at the good from the past and see if we can have some of the good things again; but if it means giving up what gained too, then we have gone backwards. The problem is how to decide what was good and what was bad? What is real progress and what is just 'showing off your money' to use a Forest Gump concept. I suspect we will argue for a long time about what qualifies as progress from the core idea of UNIX and what does not. Clem ᐧ

Well, as I look to the future I see the whole approach we have to software running into a dead end.  In fact, I think software is holding us back.   It wasn't always true.  In the old days, software ideas (like floating point, index registers, caches, etc.) proved their worth and were put into hardware to make them faster.  I think around 1980 this stopped happening.  Instead, hardware gave us 20 years of Moore's law, with ever faster and cheaper processors.   The increase in performance pretty much hid the inefficiency that the software bloat introduced. Starting about 2000, this changed.  Hardware was no longer offering increased speed.  But what it was offering was massive parallelism.  The response was to cling to the one instruction at a time model, introducing multicore and its attendant hardware complexity to try to cling to the previous model of programming.   The hardware to make this possible is expensive and does not scale. My company, Wave Computing, has built a chip with 16,000 8-bit processors on it.  And we have plans to build systems with up to a quarter million processors.  We are breaking ground in new ways to use hundreds of processors to solve problems very quickly.  It's a new way of thinking, and it makes your brain hurt.  But is is what the hardware is giving us, and there is at least another order of magnitude ahead before this trend starts running out of steam. And it's exciting... Steve ----- Original Message ----- From: "Clem Cole" &lt;clemc(a)ccc.com&gt; To: "Bakul Shah" &lt;bakul(a)bitblocks.com&gt; Cc: "The Eunuchs Hysterical Society" &lt;tuhs(a)tuhs.org&gt; Sent: Tue, 8 May 2018 10:53:16 -0400 Subject: Re: [TUHS] unix "awesome list" I'll take a slight different road on this topic.  I think we are dealing with the paradox of progress.  I don't blame Linux's developers any more than I blame BSDs or anyone else.   Really it was hardware progress/Moore's law that changed the rules :-) As much as I wax a bit for the simplicity of the Fifth, Sixth, and Seventh Editions of my youth, the truth is I would not want to try to use them today.   My needs are now different and I think the is true for most people also which is why a modern UNIX implementation is different from the original ideas or maybe I should say ideal.  That said, a lot of what I did then, ands like Steve, I still do use and many of the 'classic solutions' I find are better for me (_i.e. _troff _vs._ MS-Word) Pike's '_cat -v harmfu_l' paper foretold where we would get.   On the PDP-11 with a limited address, a programmer was constrained so you had to keep things simple.   The programming model of small simple programs that did one thing well, was easier to 'enforce.'   The ideas that formed UNIX make sense, and yoiu could build an extremely power 'system' from simple and small things.   At the time, that was almost heretical.    But once HW dropped in price and the address space issues relaxed the size of a program that could be written, people did.  The cast was out of the bag, and there was no going back.    I'm not saying all of the new BSDism of the time were right, but they certainly made many things easier/more approachable for many users and many/most live in modern UNIX definition. I think Ted makes an excellent point, that *BSD and Linux, by their nature of being 'open' and 'available' pushed the code along and that needs to continue to be the high order bit.  Open and freely available had a huge positive effect, because many of these new feature (like X-Windows, Networking) were 'useful' and the cost to add them was accessible -- so people added them.   But .... slowly the system changed and the _expectations_ of the users with them. I admit, I'm torn.   I do think Pike was right and many of the new features/frameworks _et al_ are pretty lame (useless IMHO) and the simpler/cleaner methods of old, are being ignored. Dave Pressotto and I were talking a week or so ago and Dave made the observation that he's not sure he knows how write a modern program now with all these frameworks, IDEs, _etc_ and I completely agree.  But that is the old guy in me talking; but I really do want to see progress and the new generation make its mark.  I'm sure they will do wonderful things.  Bakul's observation of little >>practical<< progress is an interesting one.   In many ways I agree, in others I'm not so sure.  I think Ted knows that my major gripe with some of the Linux (and Gnu style) community has been a focus on reimplementing things that were already there instead of using what could have been taken from somewhere else such as BSD, or replacing subsystems just because they could without really adding anything (_i.e._ the whole systemd argument). But over all, as much as I respect and think Ken and Dennis did amazing work at the time, I do tend to love when new ideas/things have been done beyond the original ideas from Ken and Dennis.  For instance, just as BSD can take credit (or blame) or sockets and making UNIX really a 'networked OS', Sun really gave us multiple file systems with the VFS, but  I strongly credit Linux for really making kernel modules a reality (yup Solaris had them, as did a few other systems - but it was really Linux that made it wide spread).   I wish Linux had taken the idea of a modular kernel a tad farther, and picked up things like Locus vproc work, because I personally think modularity under the covers is better than the containers mess we have today (and I agree with Tannenbaum that uKernel's make more sense to me in the long run - even if they do cost something in speed). it's also why I liked Plan 9 and have high hopes that a new OS, maybe written is something like Rust might finally appear.   But I don't want it re-implement UNIX or Linux.   Grab from them the subsystems that you need to duplication, but don't re-invent. Warren - at the risk of being political -- I think the paradox we have it larger than just UNIX, although it is simple.  We can wallow and say everything is bad, it was simpler in 1959 -- which exactly what some folks in my country seem to be doing in other areas.  I personally can say my world was simple in those days and I certainly have fond memories [read Bill Bryson's https://www.amazon.com/Life-Times-Thunderbolt-Kid-Memoir/dp/0767919378 [1] which parrots many of my own memories of those times ], but UNIX, like the world, has grown up and changed and is a lot more complicated.   I like progress we have now.  I don't want the world the way it was any more than I want run Fifth Edition on my Mac for day-2-day work. Yes, I would like us to look at the good from the past and see if we can have some of the good things again; but if it means giving up what gained too, then we have gone backwards.  The problem is how to decide what was good and what was bad?   What is real progress and what is just 'showing off your money' to use a Forest Gump concept. I suspect we will argue for a long time about what qualifies as progress from the core idea of UNIX and what does not. Clem ᐧ Links: ------ [1] https://www.amazon.com/Life-Times-Thunderbolt-Kid-Memoir/dp/0767919378

On Tue, May 08, 2018 at 08:31:43AM -0700, Steve Johnson wrote: What's holding us back is our human minds' ability to manage complexity. And that's the problem. If we can't program the new machines, whether it's Sun's attempt at large number of weak cores with their Niagra chips, or your company's vast number of 8-bit processors --- as the old saying goes, without software, it's just a doorstop. Moving the discussion back to Unix, the problem is that we don't have a lot of solutions to the complexity wall. The most common one seems to be deny the existence, or the validity of the requiremnts. (e.g., "Teach them all English; if 7-bit ASCII was good enough for K&R, it's good enough for me." or "Text files are all you need; why do you need new-fangled things like group calendaring or spreadsheets"?) Or you can just build on top of pre-existing systems, but then you get complaints about kludge towers and overly complex systems. Or you can give up on generality, and build a bespoke system that only addresses the problem you are paid to solve. Which may or may not be cheaper than using the more general solution and brute-forcing the problem by throwing more hardware on it, on the theory that hardware is cheaper than software engineering skills. This is not strictly true. A counter-example would be Google's Tensor Processing Units[1]. That's an example of custome hardware replacing what had previously been doing in pure software, or using more general hardware units (e.g., GPU's). Another example would be AES and SHA-256 acceleration being done in hardware in multiple CPU architectures, and in the data path between the CPU and the eMMC flash on some cell phones. [1] https://techcrunch.com/2017/05/17/google-announces-second-generation-of-ten… I think it is true we have hit the point of diminishing returns, in that as software gets more complex, finding things which are commonly used enough, and which have enough of a benefit that it is worth the engineering effort and cost of moving that functionality into hardware is much harder now compared to a few decades ago. - Ted

On May 8, 2018, at 8:31 AM, Steve Johnson &lt;scj(a)yaccman.com&gt; wrote: This sounds like a software equivalent of an FPGA! You probably have similar to "EDA" tools for placement and routing and mapping a program written in "HDL" to the underlying technology. Mapping APL to this could be fun (APL programs have a similar brain hurting side-effect!). Somewhat relevant: A retrospective on 30 years of FPGA technology: https://ieeexplore.ieee.org/document/7086413/#full-text-section

BRL had contracted with the Denver Electronics Corporation (Denelcor) to build a fluid dynamic platform. Early plans were for an analog and then hybrid computer, but this quickly evolved into the all-digital Heterogenous Element Procesor. The computer was MIMD and could run 40 or so threads simultaneously while hardware scheduling 256 times that. Each memory location in the main memory had a "full-empty" bit which allowed you to to execute instructions like "Wait until Full, then Store", and the processor handled all that. Of course, this was about the time Mike Muuss and his band were becoming real firecrackers in the labs. Mike shot his mouth off that we could put UNIX on it (our answer to everything) and the lab management took us up on the offer. Perhaps, with the exception of some of the MultibusII stuff, one of the nicest UNIX architectures around. Mike immediately set to work. He did the C compiler while Doug Kingson did the assembler. I did the loader I think. We then started on the kernel. Mike doing the low level stuff and the guts of the kernel and me doing all the IO (the "dmr" directory traditionally). About the time we got the thing running I realized that the IO performance was terrible. The thing had a sidecar unit with 32 distinct unibuses which really should have been fast enough, except the latency to start the I/Os was about ten ops/sec. Me and the HEP designer, Burton Smith sat down at the Golden Corral steakhouse in Aberdeen and designed a new processor that sat on the main memory bus. It was built out of spare HEP parts and a PDP-11/34 that I had lying around as the control processer. I through in the LOS operating system (No time for sharing -- Uniprocessor system) scavenged from my BRL Gateway code to drive it. In two days we had drastically increased the IO performance. The thing ran parallizable apps, notably Mike's BRL ray tracing "CAD" package. We pretty much used it to generate a movie of a shell's eye view of a collision with a tank. The system was replaced with a Cray XMP. Amusingly in our machine room, awaiting arrival of the HEP were taped out markings where all the cabinets went around a central building pillar. Visiting the machine in the factor, it was laid out around a taped marking showing the location of our post. -Ron

On May 8, 2018, at 7:53 AM, Clem Cole &lt;clemc(a)ccc.com&gt; wrote: Agree about the paradox of progress. Success slowed down further evolution. While h/w speed and number of gates increased tremendously the particular *direction* processor architecture took is heavily influenced by prevailing software. So I think it is really software that is to blame :-) Intel did add callgates for better containment but they didn't get used much. The price of success. It is easier to bolt-on solutions to new problems on existing platform than refine the platform. Plan9 tried that. That it failed has more to do with non-tech reasons. The lack of progress I am talking about has to do with the devil's bargain of trading simplicity for "efficiency". The 16bit CPU running at 5Mhz, with 256K of RAM and 5MB of disk in 1981 is replaced with a 64 bit processor with 16 cores, 64GB of RAM, with 10TB of disk space, with HDMI screen and 1GB/s network port (and is cheaper in terms of 1981 dollars). And yet we continue making this bargain. Pipes provided a perfect way to modularize programs. But we use shared memory and threads - mainly for squeezing out more performance. We have known about microkernels for over 30 years. CSP for over 40 years. Capability systems for over 50 years. Yet these are largely absent. Even Go provides unsafe shared memory access in spite of providing channels. Plan9 did a much cleaner job of adding filesystems and networking. May be the 9p protocol doesn't scale so well but that could've been fixed once it was used in production systems. A capability system would obviate the need for containers. If all external communication a process did was via capabilities, it doesn't matter if they directly access some physical device or virtual device, a local server or a remote server, a real file or a synthetic file. Microkernels and caps are a good match. But they too haven't been used enough in practice and will need evolution. I think it is possible to gain equivalent feature comforts using simpler systems. But my guess is "compatibility" requirement is what will hold us back.

On Tue, May 08, 2018 at 11:31:37AM -0500, Michael Parson wrote: I'm not thrilled with the systemd stuff either, I still don't see that it is solving anything that wasn't solved. But somebody must like it, it's a big change. vim, on the other hand, oh do I love me some vim. It's pretty faithful to the original vi but you get split windows, infinite undo, it remembers stuff from one invocation to the next, it's pretty sweet. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

On Tue, 8 May 2018, Larry McVoy wrote: Oh, I love VIM too, but I wish it had an "idiot" mode i.e. ignore any fumbled keys that did something strange and how do I get out of here because suddenly I see two windows when I meant to simply quit... -- Dave Horsfall BSc DTM (VK2KFU) -- FuglySoft -- Gosford IT -- Unix/C/Perl (AbW) People who fail to / understand security / surely will suffer. (tks: RichardM)

On Tue, 8 May 2018, Dave Horsfall wrote: I blame people like Lennart Poettering who seem to be hellbent on erasing Linux's origins... -uso.