On 03/19/2018 10:24 PM, Steve Nickolas wrote: Well, I think that is the general idea. At least the lower case "unix". Maybe not any specific "Unix". Things do grow / evolve / change over time. I think many people working on Linux are genuinely trying to make it better. They just have no conceptual history to guide them. What's the saying? Those who do not understand history are doomed to repeat it? (For better or worse.) -- Grant. . . . unix || die

On Mon, Mar 19, 2018 at 10:40:44PM -0600, Grant Taylor via TUHS wrote: There are also ways in which Unix is just simply deficient. For example, take syslog. It's simple, sure, but it has an extremely simple structure, and it's not nearly flexible enough for more sophisticated use cases. As a result, *many* commercial Unix systems have tried reinventing an event logging system which had more structure. Tru64 (OSF/1) had uerf. AIX had eventlog. Solaris had a structured event log as part of ILOM. And, guess what? syslog-ng came up with a set of extensions to add structure. And sytemd has come up journald. People can point at journald and laugh, and say, why so complicated? Why not the pure, simple Unix approach that was good enough for BSDh 4.3? But I'll point out that *many* commercial Unix systems had decided that syslog was not good enough, and tried to invent their own. Some that were pretty good, IMHO, and some that were a creeping horror. (And your opinion may be different than mine about which were the creeping horror. :-) So it's not so simple. Unix dind't have to deal with hardware which was hot-pluggable, for example. How you handle devices that appear and disappear after boot with a static set of device nodes in /dev is another case where different commercial Unix systems have had their own divergent idea of how to solve the system --- and of course, some completely punted and coulthdn't deal with things like USB devices at all. Early NetBSD and FreeBSD systems required a reboot when you inserted a PCMCIA card, and would crash if you ever tried to eject a PCMCIA card. You may not like Linux's solution for supporting these sorts of hardware --- but tell me: How would you hack V7 Unix to support them? - Ted

On Tue, Mar 20, 2018 at 8:31 PM, Theodore Y. Ts'o <tytso(a)mit.edu> wrote: At Netflix, we log JSON entries and scrape the logs to upload to our data base.... Simple syslogd can work, but I've often seen other packets layered upon its simple protocol... Early NetBSD and FreeBSD systems required a reboot when you inserted a To be fair, the earliest versions of Linux's PC Card support did likewise. Like the BSDs, the initial drivers were network or serial that were hacks on existing drivers that "reached over" and configured the PCIC so the device could probe. Those hacks were later replaced with better code that allowed for a wider array of drivers, as well as allowing them to come and go. The first hacks for hot-plug PCI also followed a similar trajectory: some hack to let people boot with the hardware in place, either in the driver itself, or in the bridges, followed months or years later by proper hot-plug support. USB was similar, but plug and unplug were well-trodden paths by the time it came along, so there was no lag... Much the same way that FreeBSD has gone: to move away form the hand-tweaked config tables with lots of ifdefs in v7 to having each driver self contained with an init function that registers other interesting things and a way to add to the tree dynamically after boot. But maybe I'm biased, though it is approximately the model that Linux's device discovery evolved into after trying a couple of different strategies out first... But there's many things that v7 never had to deal with: multiple CPU (everybody did that differently), dynamic devices, thousands of different devices supported by hundreds of drivers (it supports like 10 or 15 major ones), cope with large memory systems, deal with devices that had widely varying performance (all disks were the same: you submitted the request and tens of milliseconds later you got the results: no imbalances if you had a system with both NVMe with microsecond response time and tens of thousands of queue entires along with spinning rust with 10ms response time and maybe a few dozen). v7 didn't have to cope with devices that were very smart, so it didn't have to deal with dynamically balancing system resources to cope. It didn't have to deal with demand paging, or pages of different sizes. It didn't have to cope with cache coherency issues. It didn't even bother with shared libraries, nor did it require a MMU, though there were performance and security benefits. Oh, and it didn't deal with security very well by today's standards. Even so, the code is very simple to read and understand. And now that's it's available, it makes so many other decisions and design patterns make so much more sense than even finely written prose describing them. The simple elegance of its ideas and implementation afforded a clarity of design that allowed one to see the basics and hold it all in your head with not too much study. The same cannot be said for any modern OS. Warner

I've been told that syslog was came in existence as a debugging aid for sendmai. jaap

On Wed, Mar 21, 2018 at 06:18:37PM -0600, Grant Taylor via TUHS wrote: For what it is worth, the syslog/sendmail connection rings a tiny bell for me, I can't prove it either, but I feel like there was some connection. Is Eric on the list?

On Tue, Mar 20, 2018 at 10:31 PM, Theodore Y. Ts'o <tytso(a)mit.edu> wrote: ​Actually I want to +1 for both of you.​ ​I think you might be closer to agreeing than disagreeing and frankly the issue is the paradox that we live - which is called a 'success problem.'​ The magic behind Ken and Dennis's work was the simple elegance of the UNIX ideas and practical implements of those ideas that I think we on this list admire. With 'modest' hardware, the produced an amazing functional system - in fact one way more functional for their target (programmers) than their contemporary systems from ''commercial' vendors. But at the time ... we (programmers) were willing to give up some 'features' of those commercial systems that we did not value in return for a system that made more sense to us. But time did not stop and our needs as users and what we considered 'ante' to play the game much less 'jacks to open', has changed. As I point out elsewhere, as much as I pine for the simplicity of 6th and 7th editions; I believe that UNIX implementations got fat and bloated as it grew up, I would not be able to use same today as my day to day system [my favorite example of 'baddness' of an UNIX implementation was the SVR3 boot loader being so much larger than the V6 kernel - IIRC it was 2-3 times the text and data size]. That said, my own requirements for a minimal system, as have others on this list, require features that just were not there in those systems (Ted's need for a system logger to support for pluggable HW, much less basic support for networking, web browsing, better email, more languages choices, *etc*.). [I personally use a Mac as my 'primary' system, but ssh/vnc *etc* to program on Linux systems daily for work]. Larry rightly mentions 'clean and simple' as a huge part of the 'Unix philosophy' - in fact, I will take that farther to say it was the greatest gift of UNIX (the system idea as opposed the implementation). The key point is that with 'modest hardware' of the day and the limits that said hardware forced, simple and clean was required to get the job done. UNIX (the idea) gave us a way to solve complex problems without a lot of the goop that other systems had to get the same or better results. And here comes the hard part ... as the Unix implementations moved from the 16 bit resource constrained system to the VAX and the unburdening of those restrictions unleashed a new way to build tools that worked with UNIX as a system (the idea). Pike's railing on 'cat -v harmful' said it all. Basically, we forgot what was 'UNIX' - in fact we eventually started to argue about it and have not stopped since ;-) Frankly, my sisters and brothers at UCB were some of the worst offenders of the bloat, because they could be. I've always said as an example, if Eric had not put the system SMTP send/recv daemon inside of sendmail, the sendmail tool would never have spread the way it did. Under the 'pure' Unix philosophy, 'smptd' really should have been a seperate program [like it was in the original BBN networking code] and the header rewriting system, really should have been some other program; and probably a separate daemon for local delivery *i.e.* small tools to do one job. Yet it was easier for him to combine them at the time and he could, so he did. He first added the SMTP protocol to the BSD delivery agent (delivermail), and as the header wars started hacked on the program to do rewriting. The morphed as we know and the rewriting portion quickly dominated the tool. The key is that the combined result was a useful tool for BSD, and made available with BSD as the mail system. It was 'grandfathered' in at most sites that did not need to do the rewriting, because it solved the SMTPD problem well. Then they discovered the rewrite features and rest -- well we all know what happened. Did other 'better' mail agents appear for UNIX and get used in many places, sure, but for whatever reasons - never displaced it as widely. But the fact remains, sendmail is hardly a 'simple' nor 'elegant'. I personally believe that if Pressotto's email system for the V8 had been the 'Berkeley' mail (which did follow the elegant and simple 'UNIX' design), we might have seen a different history (the Morris worm for instance, would have been much less likely). Now, I ask you did we trash BSD UNIX because on of sendmail? Hardly, some people loved sendmail; others loath it and did something different. The *BSD and Linux of today are just examples same issue at the system level. Neither is better, neither is good or bad. The problem is we have these features and we are less constrained, so 'modern' programmers rarely have to think in the same terms that Ken and Dennis, so very do. Like Grant, I worry that many young programmers do not have enough the the history behind them (trying reading the questions on Quora if you want some examples of this issue). Ken and Dennis were forced to be clean and simple, few of today's programs even consider it. But, that said, we do need to remember to keep UNIX the ideas and specific implementations distinct. V7 is deficient for today's world - as Larry says - real life gets in the way. Could/Should linux (or *BSD) go on a diet? Probably, the question is can you do that reasonably and be successful. Plan 9 I think was Ken's attempt. For whatever reason, it did not take off ( I think the licensing at the time of its birth cause much of that - i.e. timing is everything). Maybe Google or someone else will be able to do something like that. If it happens, I suspect, it is not going to be Linux because it has already (like *BSD) picked up a following that is not going to give up many of the 'features' that make it useful and 'better.' Clay Christiansen tells is this in his theory, just as Linux disrupted the entrenched *BSD. For me, the key point for us, is can be teach the next generation what the core idea of UNIX is - simple and elegant. What we need to continue to learn and model the ideas and then apply the appropriately. Then whatever 'UNIX' becomes as the current implementation, be it Linux, Plan9++ or a RustOS, we get to keep the core of the system we love and admire, are able to move on to what in 'real life' fits. On another topic, as for the arguments about syslogd - the history is that sendmail had nothing to do it. VMS was more the model/reason. You need to remember, CSRG was under great pressure to build into BSD features that DoD/Arpa community that was funding them desired. Their was huge pressure at the time to use a commercial system and in fact many in Arpa wanted to be out of the computer business, *i.e. *felt that commercial firms should be doing that work. The primary 'competition' was VMS for the VAX, and at the time CSRG has a list of 'commercial OS features' that systems like TOPS-10, VMS, VM/CMS *etc.* supported that were slowly being added. Clem ᐧ

On Wed, Mar 21, 2018 at 8:18 AM, Paul Winalski <paul.winalski(a)gmail.com> wrote: "Perfection is Achieved Not When There Is Nothing More to Add, But When There Is Nothing Left to Take Away" Antoine de Saint-Exupery Warner

On Wed, Mar 21, 2018 at 9:45 AM, Andy Kosela <akosela(a)andykosela.com> wrote: I'm not so sure about that. It's installer is minimal, but there's still lots of bloat in it's kernel... Warner

On Monday, March 19, 2018, Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> wrote: I actually always liked the term 'dragons'. This I believe came from MIT. --Andy

On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson <ggm(a)algebras.org> wrote: THANK YOU! I have wondered about the etymology of the word "bus" in an electrical context for YEARS. I think daemon/demon came from printers demon, which is carved into While this story (and the others I trimmed for brevity) is (are) great, "daemon" is actually from the Greek, I believe: an intermediary between humans (users) and the gods (the kernel). - Dan C.

On Tue, Mar 20, 2018 at 2:24 PM, Bakul Shah <bakul(a)bitblocks.com> wrote: ​Right -- that is what I was under the impression from where the term came for computer use. Although, I was also under the impression that Maxwell had taken the term from ideas from some his Cambridge colleagues that were working on human thought and described the ideas of these daemons running around in your head supporting things like vision, hearing and your other senses. The later was formalized I believe years later by Oliver Suthridge (IIRC my Cog Psych of many years ago) - into the something like the Pandemonium model of cognition. i.e. I think the term was used first in Cognition, then to Physics and finally to Computers. As for Paul's comment about the daemons. Yes, Kirk McKusick who actually drew the original BSD daemon with purple sneakers, was wearing the infamous blue tee with said logo out walking on the street, as one someone else in the party (maybe Sam Leffler) sporting a 10 anniversary USENIX shirt in San Antonio many years ago, which has the daemons shown top of a PDP-11 with pipes, the null device, *et al*. He has quite a tale of the experience. Clem ᐧ

On Tue, Mar 20, 2018 at 3:10 PM, Bakul Shah <bakul(a)bitblocks.com> wrote: Oh how interesting. Of note Maxwell's first quoted letter describes the theory in terms of "finite beings"; Wikipedia claims it was Lord Kelvin who first labeled them "demons" in a paper published in the journal "Nature" in 1879 (citation here: https://www.nature.com/articles/020126a0; full text here: https://zapatopi.net/kelvin/papers/the_sorting_demon_of_maxwell.html) and that seems to be backed up by what you quoted below: Maxwell constructed the following Catechism: Here, Maxwell seems to be corresponding with Thomson in 1867 but it is not until more than a decade later Thomson writes his nature article which clearly associates the concept with to the Greek notion. Kelvin's article seems to be describing a lecture, and further seems to imply that the concept was ideas recognized -- at least in scientific circles, by 1879. Anyway, by his own admission Corbato came into contact with the concept via physics and uses it on Multics to describe programs doing more or less what any of us would think of a "daemon" doing, and from there it went into Unix. I wonder where the archaic spelling came from. So it does come from the Greek notion, albeit in a roundabout fashion. Does that seem accurate? I'm mildly surprised that such a thing would happen in San Antonio, which is a bit more cosmopolitan than much of the rest of Texas. But only mildly. - Dan C.

On Mar 20, 2018 2:58 PM, "Tim Bradshaw" <tfb(a)tfeb.org> wrote: This seems like an unduly complicated theory. Maxwell had a good 19th-century Scottish gentleman's education (he knew great chunks of Paradise Lost by heart as a child) and he would have been far more familiar with classical literature than most scientists are today as a result. Chances are he knew what daemons were in mythology because he'd read either the Greek originals or Latin translations at school & university. Given that, he could also have read about them in Plato's Republic when he discusses the myth of Er at the end of the work.

Allow me to add my 2 cents: Ancient Greece, like all other "primitive" societies that I am aware of, had beliefs in "spirits" as well as in the CxO level deities (Most hunter-gatherer and farmer/hunter Stone Age societies didn't get to the level of CxO dieties, they stuck with spirits behind everything.). The CxO deities made the policies; very few of them actually carried those policies out themselves; they relied on a bunch of lesser spirits to do them. In Classical Greek, daemonoi. Where the connection with the English word "demon" comes in, is this: the Christian Church by and large did not believe in the goodness of most of those alleged daemonoi and labelled them evil, in large part because in the Christian mythology, there is very little room for subsidiary spirits; The Christian God is a god without a specific portfolio: he runs the whole show. Heaps more history there. too much to cover. So Maxwell with his Classical education with its heavy emphasis on Latin and Greek language and culture, would've had a handy metaphor immediately understandable by all his scientific peers in the Royal Society, in France, Germany, Russia, the USA, and elsewhere. And as such, it would be easily extendable to computer science looking for a handy term to cover system-level background programs handling details that were between low-level OS procedures and functions and high-level user programs. Wesley Parish PS FWVLIW, JRR Tolkien took one specific subset of these "spirits", the woodland spirits, "baptised" them so to speak as he was a devout Catholic, and turned them into one of the axes of his fiction. Some years later Cordwainer Smith played the same trick with his Daimoni, except these Daimoni are more like spirits of the stars. So if you're a fan of both JRR Tolkien and Cordwainer Smith and wonder why they seem at times so similar, that is part of the reason. On 3/21/18, Tim Bradshaw <tfb(a)tfeb.org> wrote:

TOPS-10 had daemons (file daemon, for example). Does the TOPS-10 usage of the term predate or postdate its use in Unix? -Paul W.

On Tue, Mar 20, 2018 at 4:14 PM, Warren Toomey <wkt(a)tuhs.org> wrote: ​Indeed. Kirk ended up getting some sort of legal rights for his version of it [don't ask me which - trademark/copyright] . Sadly my wife threw out my Foglio shirt a few years after we were married (one of our first disagreements on the value of 'old' things - which continues today - now she stay out the basement where my museum is😎. In her defense, it was probably 5-6 years old then, had holes and had not worn well. The shirts were very inexpensively made and frankly after 20-30 washings, the red piping on the side had faded and a few more washing the printing started to fall off. ᐧ

On 03/20/18 14:04, Dan Cross wrote: I thought they were written buss lines until IBM started dropping an 's'. N.

On 2018-03-20 11:56, George Michaelson wrote: Could you tell us more about this 72-pin version of a pdp11?

On 2018-03-26 03:44, George Michaelson wrote: That's why I was asking. I know the J11 pretty well, with it's 60 pins, it is big. Was curious about a bigger one ;-) Cheers & thanks!