[TUHS] daemons are not to be exorcised

[TUHS] daemons are not to be exorcised

[A. P. Garcia]

Hi,

The Hacker's Dictionary says that daemons were so named in CTSS. I'm
guessing then that Ken Thompson brought them into Unix? I've noticed that
more recent implementations of init have shunned the traditional
terminology in favor of the more prosaic word "services". For example,
Solaris now has SMF, the Service Management Facility, and systemd, the
linux replacement for init, has services as well. It makes me a little sad,
because it feels like some of the imaginativeness, fancifulness, and
playfulness that imbue the Unix spirit are being lost.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180319/ebbb4e7c/attachment.html>

[TUHS] daemons are not to be exorcised

[Dave Horsfall]

On Mon, 19 Mar 2018, A. P. Garcia wrote:

> [...] It makes me a little sad, because it feels like some of the 
> imaginativeness, fancifulness, and playfulness that imbue the Unix 
> spirit are being lost.

Probably around the time that BUGS got renamed by the suits to something a 
little more marketoid-friendly?

(Still catching up on the Backus/Fortran thread, unless WKT shuts it down 
first, so no, I'm not ignoring anyone.)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] daemons are not to be exorcised

[maxigas]

"A. P. Garcia" <a.phillip.garcia at gmail.com> writes:

> The Hacker's Dictionary says that daemons were so named in CTSS. I'm
> guessing then that Ken Thompson brought them into Unix? I've noticed that
> more recent implementations of init have shunned the traditional
> terminology in favor of the more prosaic word "services". For example,
> Solaris now has SMF, the Service Management Facility, and systemd, the
> linux replacement for init, has services as well. It makes me a little sad,
> because it feels like some of the imaginativeness, fancifulness, and
> playfulness that imbue the Unix spirit are being lost.

Sweet and sour observation indeed.  I totally agree.  However, not all
is lost and there is some poetic justice in systemd being called
system-D, where the last letter still stands for a daemon.

-- 
Maxigas, kiberpunk
FA00 8129 13E9 2617 C614 0901 7879 63BC 287E D166
Lecturer in Critical Digital Media Practice
Center for Science Studies
Department of Sociology
Lancaster University

https://relay70.metatron.ai/

Unix is a Registered Bell of AT&T Trademark Laboratories. - Donn Seeley

[TUHS] daemons are not to be exorcised

[Grant Taylor]

On 03/19/2018 07:26 PM, A. P. Garcia wrote:
> It makes me a little sad, because it feels like some of the 
> imaginativeness, fancifulness, and playfulness that imbue the Unix spirit 
> are being lost.

I feel like a lot of the Unix heritage is being lost, particularly in Linux.

Exorcise your demons and feed your daemons.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180319/1b00127e/attachment.bin>

[TUHS] daemons are not to be exorcised

[Steve Nickolas]

On Mon, 19 Mar 2018, Grant Taylor via TUHS wrote:

> On 03/19/2018 07:26 PM, A. P. Garcia wrote:
>> It makes me a little sad, because it feels like some of the 
>> imaginativeness, fancifulness, and playfulness that imbue the Unix spirit 
>> are being lost.
>
> I feel like a lot of the Unix heritage is being lost, particularly in Linux.
>
> Exorcise your demons and feed your daemons.

I think some people forget that Linux is *supposed* to act like Unix.

-uso.

[TUHS] daemons are not to be exorcised

[Grant Taylor]

On 03/19/2018 10:24 PM, Steve Nickolas wrote:
> I think some people forget that Linux is *supposed* to act like Unix.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180319/db94c406/attachment.bin>

[TUHS] daemons are not to be exorcised

[A. P. Garcia]

On Mar 19, 2018 11:40 PM, "Grant Taylor via TUHS" <tuhs at minnie.tuhs.org>
wrote:

On 03/19/2018 10:24 PM, Steve Nickolas wrote:

> I think some people forget that Linux is *supposed* to act like Unix.
>

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


Aye, and the script kitties seem to have won the war to commandeer the word
hacker.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/725ce56d/attachment.html>

[TUHS] daemons are not to be exorcised

[Theodore Y. Ts'o]

On Mon, Mar 19, 2018 at 10:40:44PM -0600, Grant Taylor via TUHS wrote:
> 
> I think many people working on Linux are genuinely trying to make it better.
> They just have no conceptual history to guide them.

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

[TUHS] daemons are not to be exorcised

[Larry McVoy]

I can't +1 Ted's post enough.  I love simple, it's how I code, it's how
I design, I force everything through simple.  And Unix is like that, it's
simple.

But real life gets in the way, what Ted is saying is true.

Going forward, I wish that people tried to be simple as they tackle the 
more complicated problems we have.  I've watched stuff like the replacement
for inetd and init and just groaned.

On Tue, Mar 20, 2018 at 10:31:25PM -0400, Theodore Y. Ts'o wrote:
> On Mon, Mar 19, 2018 at 10:40:44PM -0600, Grant Taylor via TUHS wrote:
> > 
> > I think many people working on Linux are genuinely trying to make it better.
> > They just have no conceptual history to guide them.
> 
> 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

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] daemons are not to be exorcised

[Warner Losh]

On Tue, Mar 20, 2018 at 8:31 PM, Theodore Y. Ts'o <tytso at mit.edu> wrote:

> On Mon, Mar 19, 2018 at 10:40:44PM -0600, Grant Taylor via TUHS wrote:
> >
> > I think many people working on Linux are genuinely trying to make it
> better.
> > They just have no conceptual history to guide them.
>
> 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.
>

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
> PCMCIA card, and would crash if you ever tried to eject a PCMCIA card.
>

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


> 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?
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/befef091/attachment.html>

[TUHS] daemons are not to be exorcised

[Grant Taylor]

On 03/20/2018 08:31 PM, Theodore Y. Ts'o wrote:
> There are also ways in which Unix is just simply deficient.

I get the impression that you seem to think that I think that what Unix 
was around the time of BSD 4.3 was sufficient.  -  I'm not making that 
claim or even thinking it.

I'm talking about the spirit, as in "do one thing and do it well".  Not 
that e.g. syslog shall be these specific facilities and these specific 
severrities.

I want people to understand what was done, why it was done, and to the 
best of their ability, make an informed decision when changing from 
history.  -  I'd really like people to be able to answer the question 
"Why did you do <bla> differently than it was done in <blaBlaBla>.  What 
was wrong / lacking / needed to be improved from the old way."

As long as people 1) have answers to those questions and 2) can speak to 
why they did what they did, then by all means, move forward with 
something new to try.

I hear tell of people putting reverse proxies in containers in front of 
web server containers so that they can have basic traffic counters, 
which they can't get (for some unknown to me reason) from their web 
server container.  -  Where if they had bothered to ask the network 
people, there are very likely multiple ways to get said traffic 
counters.  Further, ways to do it without adding the additional 
complexity (read: exposure) / latency of additional containers.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/2d5f8b7f/attachment-0001.bin>

[TUHS] daemons are not to be exorcised

[Jaap Akkerhuis]

> On Mar 21, 2018, at 3:31, Theodore Y. Ts'o <tytso at mit.edu> 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.

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

	jaap

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/d5eef898/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: Message signed with OpenPGP
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/d5eef898/attachment.sig>

[TUHS] daemons are not to be exorcised

[Grant Taylor]

On 03/21/2018 03:16 AM, Jaap Akkerhuis wrote:
> I've been told that syslog was came in existence as a debugging aid for 
> sendmai.

I can't prove to the contrary.  But that does seem a little extreme to me.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/e4dc0e27/attachment-0001.bin>

[TUHS] daemons are not to be exorcised

[Larry McVoy]

On Wed, Mar 21, 2018 at 06:18:37PM -0600, Grant Taylor via TUHS wrote:
> On 03/21/2018 03:16 AM, Jaap Akkerhuis wrote:
> >I've been told that syslog was came in existence as a debugging aid for
> >sendmai.
> 
> I can't prove to the contrary.  But that does seem a little extreme to me.

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?

[TUHS] syslog (was Re: daemons are not to be exorcised)

[Jeremy C. Reed]

On Wed, 21 Mar 2018, Larry McVoy wrote:

> On Wed, Mar 21, 2018 at 06:18:37PM -0600, Grant Taylor via TUHS wrote:
> > On 03/21/2018 03:16 AM, Jaap Akkerhuis wrote:
> > >I've been told that syslog was came in existence as a debugging aid for
> > >sendmai.
> > 
> > I can't prove to the contrary.  But that does seem a little extreme to me.
> 
> 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?

Allman's logging was somewhat in 4BSD (4.0).

#               -DLOG -- include log information.  This is probably
#                       only useful on systems that include the logger.

delivermail was build with that flag.
But it used log.h which was not shipped in the version I have.
Some of the code has ifdef LOG and some doesn't.

2.79BSD (from McKusick's disk) which is later has logmsg(3) manual and 
its corresponding syslog(8) daemon manual (both Feb 5 1981).

I cannot find those files online so here they are:
http://reedmedia.net/~reed/tmp-oicyi3t6984y/logmsg.3.txt
Notice that it says "12/31/79"

http://reedmedia.net/~reed/tmp-oicyi3t6984y/syslog.8.txt

But no code there for logmsg, initlog, nor syslog.

(Note that uucp's logent.c has a syslog() but that is different.)

McKusick said that syslog was first in 4.1c and official in 4.2.
In both places shipped with sendmail code.
He said it was one of the first applications to use sockets.

4.1c.1 version says "reads datagrams from an IPC port
(currently port 2222, for no good reason)"
It uses the /etc/syslog.conf file.

Allman's 4.1c.1 code says:
**      This program implements a system log, implemented as the
**      "/dev/log" mpx file on a pre-4.2bsd system or a port on
**      a post-4.2bsd system.

I think this code is not in the dspinellis/unix-history-repo
(if you find it, please teach me how to find it).

The 4.1c code entirely changed api naming and some usage from

       initlog("delivermail", 0, LOG_INDEP);

to

        openlog("sendmail", LOG_PID);

(even though comments in syslog.h and syslog.c still mentioned initlog)

and from:

logmsg(LOG_INFO, "%s->%s: %ld: %s", From.q_paddr, To, MsgSize, statmsg);

to like:

syslog(LOG_INFO, "%s: message-id=%s", e->e_id, p);

even though syslog.c there defined logmsg() use and  not syslog()

I may have overlooked but don't see any use of the code outside of 
sendmail in 4.1c. The logger.c  (without manpage) utility was included 
in the sendmail source.

4.2 shipped two version of syslog(3) source code that no longer had 
logmsg() api. (One in libc and one with sendmail.)

4.2 could started it with rc.local. While I didn't see other use of it, 
a syslog.3 showed another example use:

openlog("serverftp", LOG_PID);

4.3 finally had lots of use (including in contrib): comsat, courier, 
various mh daemons, nntpd, savecore, shutdown, lpd, telnetd, r services, 
inetd, named, and much more. Even the date tool:

        syslog(LOG_NOTICE, "set by %s", username);

[TUHS] daemons are not to be exorcised

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7414 bytes --]

On Tue, Mar 20, 2018 at 10:31 PM, Theodore Y. Ts'o <tytso at mit.edu> wrote:

> On Mon, Mar 19, 2018 at 10:40:44PM -0600, Grant Taylor via TUHS wrote:
> >
> > I think many people working on Linux are genuinely trying to make it
> better.
> > They just have no conceptual history to guide them.
>
> There are also ways in which Unix is just simply deficient.

​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





ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/09beb7d7/attachment.html>

[TUHS] daemons are not to be exorcised

[Paul Winalski]

On Tue, Mar 20, 2018 at 10:31 PM, Theodore Y. Ts'o <tytso at mit.edu> wrote:
>
> On Mon, Mar 19, 2018 at 10:40:44PM -0600, Grant Taylor via TUHS wrote:
> >
> > I think many people working on Linux are genuinely trying to make it better.
> > They just have no conceptual history to guide them.
>
> There are also ways in which Unix is just simply deficient.
>
I think a corollary of Albert Einstein's aphorism regarding theories
applies here: "Features should be as simple as possible, but no
simpler."

-Paul W.

[TUHS] daemons are not to be exorcised

[Warner Losh]

On Wed, Mar 21, 2018 at 8:18 AM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> On Tue, Mar 20, 2018 at 10:31 PM, Theodore Y. Ts'o <tytso at mit.edu> wrote:
> >
> > On Mon, Mar 19, 2018 at 10:40:44PM -0600, Grant Taylor via TUHS wrote:
> > >
> > > I think many people working on Linux are genuinely trying to make it
> better.
> > > They just have no conceptual history to guide them.
> >
> > There are also ways in which Unix is just simply deficient.
> >
> I think a corollary of Albert Einstein's aphorism regarding theories
> applies here: "Features should be as simple as possible, but no
> simpler."
>

"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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/17614ff9/attachment.html>

[TUHS] daemons are not to be exorcised

[Andy Kosela]

On Wednesday, March 21, 2018, Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Wed, Mar 21, 2018 at 8:18 AM, Paul Winalski <paul.winalski at gmail.com>
> wrote:
>
>> On Tue, Mar 20, 2018 at 10:31 PM, Theodore Y. Ts'o <tytso at mit.edu> wrote:
>> >
>> > On Mon, Mar 19, 2018 at 10:40:44PM -0600, Grant Taylor via TUHS wrote:
>> > >
>> > > I think many people working on Linux are genuinely trying to make it
>> better.
>> > > They just have no conceptual history to guide them.
>> >
>> > There are also ways in which Unix is just simply deficient.
>> >
>> I think a corollary of Albert Einstein's aphorism regarding theories
>> applies here: "Features should be as simple as possible, but no
>> simpler."
>>
>
> "Perfection is Achieved Not When There Is Nothing More to Add, But When
> There Is Nothing Left to Take Away" Antoine de Saint-Exupery
>
>
There are two kinds of people in this world.  Those that think that adding
more is better (more is more approach), and those that think the complete
opposite (less is more approach).  The second type is usually associated
with minimalistic philosophy and approach to life.  I believe Ken and the
team were the masters of minimalism.

Today the only current OS that I can think of that still adores this
minimalistic approach is probably only OpenBSD.  Even its installer is as
minimal as you can get... I really like it.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/91777e1e/attachment-0001.html>

[TUHS] daemons are not to be exorcised

[Warner Losh]

On Wed, Mar 21, 2018 at 9:45 AM, Andy Kosela <akosela at andykosela.com> wrote:

>
>
> On Wednesday, March 21, 2018, Warner Losh <imp at bsdimp.com> wrote:
>
>>
>>
>> On Wed, Mar 21, 2018 at 8:18 AM, Paul Winalski <paul.winalski at gmail.com>
>> wrote:
>>
>>> On Tue, Mar 20, 2018 at 10:31 PM, Theodore Y. Ts'o <tytso at mit.edu>
>>> wrote:
>>> >
>>> > On Mon, Mar 19, 2018 at 10:40:44PM -0600, Grant Taylor via TUHS wrote:
>>> > >
>>> > > I think many people working on Linux are genuinely trying to make it
>>> better.
>>> > > They just have no conceptual history to guide them.
>>> >
>>> > There are also ways in which Unix is just simply deficient.
>>> >
>>> I think a corollary of Albert Einstein's aphorism regarding theories
>>> applies here: "Features should be as simple as possible, but no
>>> simpler."
>>>
>>
>> "Perfection is Achieved Not When There Is Nothing More to Add, But When
>> There Is Nothing Left to Take Away" Antoine de Saint-Exupery
>>
>>
> There are two kinds of people in this world.  Those that think that adding
> more is better (more is more approach), and those that think the complete
> opposite (less is more approach).  The second type is usually associated
> with minimalistic philosophy and approach to life.  I believe Ken and the
> team were the masters of minimalism.
>
> Today the only current OS that I can think of that still adores this
> minimalistic approach is probably only OpenBSD.  Even its installer is as
> minimal as you can get... I really like it.
>

I'm not so sure about that. It's installer is minimal, but there's still
lots of bloat in it's kernel...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/20849702/attachment.html>

[TUHS] daemons are not to be exorcised

[Grant Taylor]

On 03/21/2018 07:59 AM, Clem Cole wrote:
> 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.'

I suspect the container / lightweight VM movement will help with some of 
this.

People are learning the value of smaller, easier to maintain containers 
/ VMs.  Granted, containers are multi-OS and not just unix.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/8d8031df/attachment.bin>

[TUHS] daemons are not to be exorcised

[Andy Kosela]

On Monday, March 19, 2018, Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:

> On 03/19/2018 07:26 PM, A. P. Garcia wrote:
>
>> It makes me a little sad, because it feels like some of the
>> imaginativeness, fancifulness, and playfulness that imbue the Unix spirit
>> are being lost.
>>
>
> I feel like a lot of the Unix heritage is being lost, particularly in
> Linux.
>
> Exorcise your demons and feed your daemons.
>
>
I actually always liked the term 'dragons'.  This I believe came from MIT.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/5e812581/attachment-0001.html>

[TUHS] daemons are not to be exorcised

[Nemo]

On 20/03/2018, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> On 03/19/2018 07:26 PM, A. P. Garcia wrote:
>> It makes me a little sad, because it feels like some of the
>> imaginativeness, fancifulness, and playfulness that imbue the Unix spirit
>> are being lost.
>
> I feel like a lot of the Unix heritage is being lost, particularly in Linux.

Indeed, Wise Henry today would have written: Eschew the heresy that
all's the world Linux.  (And try building something such as llvm on a
UNIX box.)

> Exorcise your demons and feed your daemons.

There is a wonderful image with caption "/etc/init.d/daemon stop".
Easily found but I give no link because I cannot ascertain the
copyright.

N.

> --
> Grant. . . .
> unix || die

[TUHS] daemons are not to be exorcised

[Paul Winalski]

On 3/19/18, A. P. Garcia <a.phillip.garcia at gmail.com> wrote:
>
> I've noticed that
> more recent implementations of init have shunned the traditional
> terminology in favor of the more prosaic word "services". For example,
> Solaris now has SMF, the Service Management Facility, and systemd, the
> linux replacement for init, has services as well. It makes me a little sad,
> because it feels like some of the imaginativeness, fancifulness, and
> playfulness that imbue the Unix spirit are being lost.
>
The term "daemon" doesn't go down very well with some Christians.  I
know of hackers wearing clothing depicting the BSD daemon being
hassled in Texas and other places in the deep South.  Replacing
"daemons" with "services" is probably a concession to the fundies.  I
agree it's rather sad.

-Paul W.

[TUHS] daemons are not to be exorcised

[George Michaelson]

we call them "busses" because back in the day, real electrical
engineers called any huge solid carrier of signal or power a bus line,
because it looked like the way trolly busses got their power.

I think daemon/demon came from printers demon, which is carved into
the government printing office in Brisbane. the printers demon is the
one which stuffed up letters in the tray, to make printers tear their
hair out. Did I say tray? I meant case, upper case, the one above,
with the big letters, and lower case, the case with the little
letters. oh dear. really? is that why they are cases?

data bus cables used to be the size of a moderate Dr Who Scarf, and
just as colourful. Now we're all settled on terahertz speed 2 wire
protocols or even one-wire, Its all a bit moot. At least we still talk
about the backplane, but usually now, its connecting the edge of a CPU
cluster, to the combination of power and a switch fabric. I dont think
people assume a computer spans more than one card any more, unless its
Intel struggling to fit the CPU on one chip, mounting two chips side
by side and then spreading the power budget into two lines on the bus.
Oh dear..

I got given the last generation PDP-11 on a chip, in a 72pin DIP. I
gave it to somebody else who could use it. At the time, I thought it
was Teh Awesome l33t to have an entire pdp11 on one chip. imagine! my
god, the power, the power. I think the day is coming when a CPU has
gold pins top and bottom. they have a very large number of pins.
Somebody smart will have to invent code to work out how to wire the
pins. Oh, hang on, thats why Djikstra's algorrithm which lies at the
heart of routing protocols was written back in the day. oh dear.. its
turtles all the way down isn't it?

On Tue, Mar 20, 2018 at 5:48 PM, Paul Winalski <paul.winalski at gmail.com> wrote:
> On 3/19/18, A. P. Garcia <a.phillip.garcia at gmail.com> wrote:
>>
>> I've noticed that
>> more recent implementations of init have shunned the traditional
>> terminology in favor of the more prosaic word "services". For example,
>> Solaris now has SMF, the Service Management Facility, and systemd, the
>> linux replacement for init, has services as well. It makes me a little sad,
>> because it feels like some of the imaginativeness, fancifulness, and
>> playfulness that imbue the Unix spirit are being lost.
>>
> The term "daemon" doesn't go down very well with some Christians.  I
> know of hackers wearing clothing depicting the BSD daemon being
> hassled in Texas and other places in the deep South.  Replacing
> "daemons" with "services" is probably a concession to the fundies.  I
> agree it's rather sad.
>
> -Paul W.

[TUHS] daemons are not to be exorcised

[Dan Cross]

On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson <ggm at algebras.org> wrote:

> we call them "busses" because back in the day, real electrical
> engineers called any huge solid carrier of signal or power a bus line,
> because it looked like the way trolly busses got their power.
>

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
> the government printing office in Brisbane. the printers demon is the
> one which stuffed up letters in the tray, to make printers tear their
> hair out. Did I say tray? I meant case, upper case, the one above,
> with the big letters, and lower case, the case with the little
> letters. oh dear. really? is that why they are cases?
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/653118ca/attachment-0001.html>

[TUHS] daemons are not to be exorcised

[Bakul Shah]

On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross <crossd at gmail.com> wrote:
Dan Cross writes:
> 
> On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson <ggm at algebras.org> wrote:
> 
> I think daemon/demon came from printers demon, which is carved into
> > the government printing office in Brisbane. the printers demon is the
> > one which stuffed up letters in the tray, to make printers tear their
> > hair out. Did I say tray? I meant case, upper case, the one above,
> > with the big letters, and lower case, the case with the little
> > letters. oh dear. really? is that why they are cases?
> >
> 
> 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).

From http://ei.cs.vt.edu/~history/Daemon.html

  Fernando J. Corbato: ... Our use of the word daemon (@
  Project MAC in 1963) was inspired by the Maxwell's daemon of
  physics and thermodynamics. (My background is Physics.)
  Maxwell's daemon was an imaginary agent which helped sort
  molecules of different speeds and worked tirelessly in the
  background. We fancifully began to use the word daemon to
  describe background processes which worked tirelessly to
  perform system chores.

[TUHS] daemons are not to be exorcised

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2704 bytes --]

On Tue, Mar 20, 2018 at 2:24 PM, Bakul Shah <bakul at bitblocks.com> wrote:

> On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross <crossd at gmail.com> wrote:
> Dan Cross writes:
> >
> > On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson <ggm at algebras.org>
> wrote:
> >
> > I think daemon/demon came from printers demon, which is carved into
> > > the government printing office in Brisbane. the printers demon is the
> > > one which stuffed up letters in the tray, to make printers tear their
> > > hair out. Did I say tray? I meant case, upper case, the one above,
> > > with the big letters, and lower case, the case with the little
> > > letters. oh dear. really? is that why they are cases?
> > >
> >
> > 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).
>
> From http://ei.cs.vt.edu/~history/Daemon.html
>
>   Fernando J. Corbato: ... Our use of the word daemon (@
>   Project MAC in 1963) was inspired by the Maxwell's daemon of
>   physics and thermodynamics. (My background is Physics.)
>   Maxwell's daemon was an imaginary agent which helped sort
>   molecules of different speeds and worked tirelessly in the
>   background. We fancifully began to use the word daemon to
>   describe background processes which worked tirelessly to
> ​​
>
>   perform system chores.
>


​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





ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/80d92bda/attachment.html>

[TUHS] daemons are not to be exorcised

[Bakul Shah]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3344 bytes --]

On Mar 20, 2018, at 11:46 AM, Clem Cole <clemc at ccc.com> wrote:
> 
> On Tue, Mar 20, 2018 at 2:24 PM, Bakul Shah <bakul at bitblocks.com> wrote:
> On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross <crossd at gmail.com> wrote:
> Dan Cross writes:
> >
> > On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson <ggm at algebras.org> wrote:
> >
> > I think daemon/demon came from printers demon, which is carved into
> > > the government printing office in Brisbane. the printers demon is the
> > > one which stuffed up letters in the tray, to make printers tear their
> > > hair out. Did I say tray? I meant case, upper case, the one above,
> > > with the big letters, and lower case, the case with the little
> > > letters. oh dear. really? is that why they are cases?
> > >
> >
> > 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).
> 
> From http://ei.cs.vt.edu/~history/Daemon.html
> 
>   Fernando J. Corbato: ... Our use of the word daemon (@
>   Project MAC in 1963) was inspired by the Maxwell's daemon of
>   physics and thermodynamics. (My background is Physics.)
>   Maxwell's daemon was an imaginary agent which helped sort
>   molecules of different speeds and worked tirelessly in the
>   background. We fancifully began to use the word daemon to
>   describe background processes which worked tirelessly to​​
>   perform system chores.
> 
> 
> ​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.

This origin must've been better known 30+ years back because I
remembered this as well. To check I first looked at the Wikipedia
entry for Maxwell's demons (I learned new facts but also confused
myself as I couldn't see the connection).

As to where Maxwell got his demons, see
https://archive.org/stream/lifescientificwo00knotuoft#page/212/mode/2up
and page 214 as well:

  Maxwell constructed the following Catechism:
  
    "Concerning demons.
    "1. Who gave them this name? Thomson
    "2. What were they by nature? Very small BUT lively beings incapable of 
        doing work but also able to open and shut valves which move without
        friction or inertia.
    etc.


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

BSD's daemon is much cuter than that damned nemesis of Batman :-)

[TUHS] daemons are not to be exorcised

[Dan Cross]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5052 bytes --]

On Tue, Mar 20, 2018 at 3:10 PM, Bakul Shah <bakul at bitblocks.com> wrote:

> On Mar 20, 2018, at 11:46 AM, Clem Cole <clemc at ccc.com> wrote:
> >
> > On Tue, Mar 20, 2018 at 2:24 PM, Bakul Shah <bakul at bitblocks.com> wrote:
> > On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross <crossd at gmail.com> wrote:
> > Dan Cross writes:
> > >
> > > On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson <ggm at algebras.org>
> wrote:
> > >
> > > I think daemon/demon came from printers demon, which is carved into
> > > > the government printing office in Brisbane. the printers demon is the
> > > > one which stuffed up letters in the tray, to make printers tear their
> > > > hair out. Did I say tray? I meant case, upper case, the one above,
> > > > with the big letters, and lower case, the case with the little
> > > > letters. oh dear. really? is that why they are cases?
> > > >
> > >
> > > 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).
> >
> > From http://ei.cs.vt.edu/~history/Daemon.html
> >
> >   Fernando J. Corbato: ... Our use of the word daemon (@
> >   Project MAC in 1963) was inspired by the Maxwell's daemon of
> >   physics and thermodynamics. (My background is Physics.)
> >   Maxwell's daemon was an imaginary agent which helped sort
> >   molecules of different speeds and worked tirelessly in the
> >   background. We fancifully began to use the word daemon to
> >   describe background processes which worked tirelessly to​​
> >   perform system chores.
> >
> >
> > ​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.
>
> This origin must've been better known 30+ years back because I
> remembered this as well. To check I first looked at the Wikipedia
> entry for Maxwell's demons (I learned new facts but also confused
> myself as I couldn't see the connection).
>
> As to where Maxwell got his demons, see
> https://archive.org/stream/lifescientificwo00knotuoft#page/212/mode/2up
> and page 214 as well:
>

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:
>
>     "Concerning demons.
>     "1. Who gave them this name? Thomson
>     "2. What were they by nature? Very small BUT lively beings incapable of
>         doing work but also able to open and shut valves which move without
>         friction or inertia.
>     etc.


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.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.
>
> BSD's daemon is much cuter than that damned nemesis of Batman :-)


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/a1f2534c/attachment.html>

[TUHS] daemons are not to be exorcised

[Tim Bradshaw]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3559 bytes --]

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.

Even today the term can be used without the connotations of evil that it often has: His Dark Materials has daemons which are not in any way evil.  Perhaps significantly it is heavily influenced by Paradise Lost as well: perhaps the common source is that.  I have a copy but I haven't read it, sadly.

> On 20 Mar 2018, at 18:46, Clem Cole <clemc at ccc.com> wrote:
> 
> 
> 
>> On Tue, Mar 20, 2018 at 2:24 PM, Bakul Shah <bakul at bitblocks.com> wrote:
>> On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross <crossd at gmail.com> wrote:
>> Dan Cross writes:
>> >
>> > On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson <ggm at algebras.org> wrote:
>> >
>> > I think daemon/demon came from printers demon, which is carved into
>> > > the government printing office in Brisbane. the printers demon is the
>> > > one which stuffed up letters in the tray, to make printers tear their
>> > > hair out. Did I say tray? I meant case, upper case, the one above,
>> > > with the big letters, and lower case, the case with the little
>> > > letters. oh dear. really? is that why they are cases?
>> > >
>> >
>> > 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).
>> 
>> From http://ei.cs.vt.edu/~history/Daemon.html
>> 
>>   Fernando J. Corbato: ... Our use of the word daemon (@
>>   Project MAC in 1963) was inspired by the Maxwell's daemon of
>>   physics and thermodynamics. (My background is Physics.)
>>   Maxwell's daemon was an imaginary agent which helped sort
>>   molecules of different speeds and worked tirelessly in the
>>   background. We fancifully began to use the word daemon to
>>   describe background processes which worked tirelessly to​​
>>   perform system chores.
> 
> 
> ​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
> 
> 
> 
> 
> 
> ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/5dbfc37d/attachment-0001.html>

[TUHS] daemons are not to be exorcised

[A. P. Garcia]

On Mar 20, 2018 2:58 PM, "Tim Bradshaw" <tfb at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/9f4d8e40/attachment-0001.html>

[TUHS] daemons are not to be exorcised

[Andy Kosela]

On Tuesday, March 20, 2018, A. P. Garcia <a.phillip.garcia at gmail.com> wrote:

>
>
> On Mar 20, 2018 2:58 PM, "Tim Bradshaw" <tfb at 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.
>

Exactly.  Plato also writes extensively on it in his other works, e.g.
Cratylus.  He is using the term 'daimones' and it could be best described
as the guardian angel of the Christians.  So there is a big difference
between evil demons (devils) of Christianity and the daimon of Socrates and
Plato.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/b9d5d8ec/attachment-0001.html>

[TUHS] daemons are not to be exorcised

[Wesley Parish]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5463 bytes --]

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 at 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.
>
> Even today the term can be used without the connotations of evil that it
> often has: His Dark Materials has daemons which are not in any way evil.
> Perhaps significantly it is heavily influenced by Paradise Lost as well:
> perhaps the common source is that.  I have a copy but I haven't read it,
> sadly.
>
>> On 20 Mar 2018, at 18:46, Clem Cole <clemc at ccc.com> wrote:
>>
>>
>>
>>> On Tue, Mar 20, 2018 at 2:24 PM, Bakul Shah <bakul at bitblocks.com> wrote:
>>> On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross <crossd at gmail.com> wrote:
>>> Dan Cross writes:
>>> >
>>> > On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson <ggm at algebras.org>
>>> > wrote:
>>> >
>>> > I think daemon/demon came from printers demon, which is carved into
>>> > > the government printing office in Brisbane. the printers demon is
>>> > > the
>>> > > one which stuffed up letters in the tray, to make printers tear
>>> > > their
>>> > > hair out. Did I say tray? I meant case, upper case, the one above,
>>> > > with the big letters, and lower case, the case with the little
>>> > > letters. oh dear. really? is that why they are cases?
>>> > >
>>> >
>>> > 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).
>>>
>>> From http://ei.cs.vt.edu/~history/Daemon.html
>>>
>>>   Fernando J. Corbato: ... Our use of the word daemon (@
>>>   Project MAC in 1963) was inspired by the Maxwell's daemon of
>>>   physics and thermodynamics. (My background is Physics.)
>>>   Maxwell's daemon was an imaginary agent which helped sort
>>>   molecules of different speeds and worked tirelessly in the
>>>   background. We fancifully began to use the word daemon to
>>>   describe background processes which worked tirelessly to​​
>>>   perform system chores.
>>
>>
>> ​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
>>
>>
>>
>>
>>
>> ᐧ
>

[TUHS] daemons are not to be exorcised

[Warren Toomey]

On Tue, Mar 20, 2018 at 02:46:00PM -0400, Clem Cole wrote:
>   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.

The daemons on the PDP-11 with pipes was drawn by Phil Foglio:
https://www.mckusick.com/beastie/shirts/usenix.html

and this image was the inspiration for the BSD daemon.

Cheers, Warren

[TUHS] daemons are not to be exorcised

[Paul Winalski]

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.

[TUHS] daemons are not to be exorcised

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

On Tue, Mar 20, 2018 at 4:25 PM, Paul Winalski <paul.winalski at gmail.com>
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.
>

​It was all pretty contemporary in my view. I suspect CTSS was first and
the others picked up the idea from there. Univac EXEC-8 called them
'symbiants' as I recall, and I think TSS used the term 'system tasks' but
we did refer to them as daemons also. Of course, I saw them called daemons
on TOPS and UNIX around the same time and never really made a big deal one
way or the other; again I think because we used the term on the IBM systems
sometimes.

Clem

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/7ed772bf/attachment.html>

[TUHS] daemons are not to be exorcised

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]

On Tue, Mar 20, 2018 at 4:14 PM, Warren Toomey <wkt at tuhs.org> wrote:

> On Tue, Mar 20, 2018 at 02:46:00PM -0400, Clem Cole wrote:
>
>>   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.
>>
>
> The daemons on the PDP-11 with pipes was drawn by Phil Foglio:
> https://www.mckusick.com/beastie/shirts/usenix.html
>
> and this image was the inspiration for the BSD daemon.
>

​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.
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/0dcdacb4/attachment.html>

[TUHS] daemons are not to be exorcised

[Toby Thain]

On 2018-03-20 2:24 PM, Bakul Shah wrote:
> On Tue, 20 Mar 2018 14:04:38 -0400 Dan Cross <crossd at gmail.com> wrote:
> Dan Cross writes:
>>
>> On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson <ggm at algebras.org> wrote:
>>
>> I think daemon/demon came from printers demon, which is carved into
>>> the government printing office in Brisbane. the printers demon is the
>>> one which stuffed up letters in the tray, to make printers tear their
>>> hair out. Did I say tray? I meant case, upper case, the one above,
>>> with the big letters, and lower case, the case with the little
>>> letters. oh dear. really? is that why they are cases?
>>>
>>
>> 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).
> 
>From http://ei.cs.vt.edu/~history/Daemon.html
> 
>   Fernando J. Corbato: ... Our use of the word daemon (@
>   Project MAC in 1963) was inspired by the Maxwell's daemon of
>   physics and thermodynamics. (My background is Physics.)
>   Maxwell's daemon was an imaginary agent which helped sort
>   molecules of different speeds and worked tirelessly in the
>   background. We fancifully began to use the word daemon to
>   describe background processes which worked tirelessly to
>   perform system chores.
> 

OK, but where did Maxwell get it? :-)

[TUHS] daemons are not to be exorcised

[Nemo Nusquam]

On 03/20/18 14:04, Dan Cross wrote:
> On Tue, Mar 20, 2018 at 1:56 PM, George Michaelson <ggm at algebras.org
> <mailto:ggm at algebras.org>> wrote:
>
>     we call them "busses" because back in the day, real electrical
>     engineers called any huge solid carrier of signal or power a bus line,
>     because it looked like the way trolly busses got their power.
>
>
> THANK YOU! I have wondered about the etymology of the word "bus" in an
> electrical context for YEARS.

I thought they were written buss lines until IBM started dropping an 's'.

N.

[TUHS] daemons are not to be exorcised

[emanuel stiebler]

On 2018-03-20 18:56, George Michaelson wrote:

> I got given the last generation PDP-11 on a chip, in a 72pin DIP. I
> gave it to somebody else who could use it. 

72 pins?

[TUHS] daemons are not to be exorcised

[emanuel stiebler]

On 2018-03-20 11:56, George Michaelson wrote:
> I got given the last generation PDP-11 on a chip, in a 72pin DIP. I
> gave it to somebody else who could use it. At the time, I thought it
> was Teh Awesome l33t to have an entire pdp11 on one chip. imagine! my
> god, the power, the power. I think the day is coming when a CPU has
> gold pins top and bottom. they have a very large number of pins.
> Somebody smart will have to invent code to work out how to wire the
> pins. Oh, hang on, thats why Djikstra's algorrithm which lies at the
> heart of routing protocols was written back in the day. oh dear.. its
> turtles all the way down isn't it?

Could you tell us more about this 72-pin version of a pdp11?

[TUHS] daemons are not to be exorcised

[George Michaelson]

I never ran it. It was a huge, ceramic enclosed DIP. Ginormous.
BIggest chip I'd ever seen. I think it required dual voltages.

I can see specsheets for what is called a J11. I don't think I
remember it looking like that, but it was a long time ago.

-G

On Sun, Mar 25, 2018 at 7:56 PM, emanuel stiebler <emu at e-bbes.com> wrote:
> On 2018-03-20 11:56, George Michaelson wrote:
>> I got given the last generation PDP-11 on a chip, in a 72pin DIP. I
>> gave it to somebody else who could use it. At the time, I thought it
>> was Teh Awesome l33t to have an entire pdp11 on one chip. imagine! my
>> god, the power, the power. I think the day is coming when a CPU has
>> gold pins top and bottom. they have a very large number of pins.
>> Somebody smart will have to invent code to work out how to wire the
>> pins. Oh, hang on, thats why Djikstra's algorrithm which lies at the
>> heart of routing protocols was written back in the day. oh dear.. its
>> turtles all the way down isn't it?
>
> Could you tell us more about this 72-pin version of a pdp11?

[TUHS] daemons are not to be exorcised

[emanuel stiebler]

On 2018-03-26 03:44, George Michaelson wrote:
> I never ran it. It was a huge, ceramic enclosed DIP. Ginormous.
> BIggest chip I'd ever seen. I think it required dual voltages.
>
> I can see specsheets for what is called a J11. I don't think I
> remember it looking like that, but it was a long time ago.

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!


> -G
>
> On Sun, Mar 25, 2018 at 7:56 PM, emanuel stiebler <emu at e-bbes.com> wrote:
>> On 2018-03-20 11:56, George Michaelson wrote:
>>> I got given the last generation PDP-11 on a chip, in a 72pin DIP. I
>>> gave it to somebody else who could use it. At the time, I thought it
>>> was Teh Awesome l33t to have an entire pdp11 on one chip. imagine! my
>>> god, the power, the power. I think the day is coming when a CPU has
>>> gold pins top and bottom. they have a very large number of pins.
>>> Somebody smart will have to invent code to work out how to wire the
>>> pins. Oh, hang on, thats why Djikstra's algorrithm which lies at the
>>> heart of routing protocols was written back in the day. oh dear.. its
>>> turtles all the way down isn't it?
>>
>> Could you tell us more about this 72-pin version of a pdp11?
>
>

[TUHS] daemons are not to be exorcised

[Nelson H. F. Beebe]

Peter Guthrie Tait (1831--1901) seems to have recorded the oldest
mention of the thermodynamic demon of James {Clerk Maxwell} in the
page 213 image from Tait's book ``Sketch of Thermodynamics'' at

	https://archive.org/stream/lifescientificwo00knotuoft#page/212/mode/2up

that was posted to this list by Bakul Shah <bakul at bitblocks.com> on
Tue, 20 Mar 2018 12:10:37 -0700.

I've been working on a bibliography (still unreleased) of Clerk
Maxwell, and the oldest reference that I had so far found to Maxwell's
demon is from an address by Sir William Thomson (later raised to Lord
Kelvin) entitled

	The sorting demon of Maxwell: [Abstract of a Friday evening
	Lecture before the Royal Institution of Great Britain,
	February 28, 1879]
	Proceedings of the Royal Institution of Great Britain 9,
	113--114 (1882)

However, I've not been able to find that volume online.  Hathi Trust
has only volumes 30--71, with numerous holes, and often, it will not
show page contents at all.  The journal issue is old enough that few
university libraries are likely to have it, but it is probably
available through the Interlibrary Loan service.

I had also recorded

	Harold Whiting
	Maxwell's demons
	Science (new series) 6(130), 83, July 1885
	https://doi.org/10.1126/science.ns-6.130.83

and
	W. Ehrenberg
	Maxwell's demon
	Scientific American 217(5) 103--110, November 1967
	https://doi.org/10.1038/scientificamerican1167-103

plus numerous later papers and books.

I also went through a score of books on my shelf about physics or
thermodynamics, and finally found a brief mention of Maxwell's demon
in G. N. Lewis & M. Randall's famous text ``Thermodynamics'', first
published in 1923 (I have a 1961 reprint).  The other books that I
checked remain strangely silent on that topic.

The Oxford English Dictionary (OED) online has this definition and
etymology:

>> ...
>> Maxwell's demon n. (also Maxwell demon) an entity imagined by Maxwell
>> as allowing only fast-moving molecules to pass through a hole in one
>> direction and only slow-moving ones in the other direction, so that if
>> the hole is in a partition dividing a gas-filled vessel, one side
>> becomes warmer and the other cooler, in contradiction of the second
>> law of thermodynamics.
>>
>> 1879 W. Thomson in Proc. Royal Inst. 9 113 Clerk Maxwell's `demon' is
>>      a creature of imagination.., invented to help us to understand the
>>      `Dissipation of Energy' in nature.
>>
>> 1885 Science 31 July 83/1 (heading) Maxwell's demons.
>>
>> 1956 E. H. Hutten Lang. Mod. Physics iv. 152 It would require a
>>      Maxwell demon..to select the rapidly moving molecules according to
>>      their velocity and concentrate them in one corner of the vessel.
>>
>> 1971 Sci. Amer. Sept. 182/2 Maxwell's demon became an intellectual
>>      thorn in the side of thermodynamicists for almost a century. The
>>      challenge to the second law of thermodynamics was this: Is the
>>      principle of the increase of entropy in all spontaneous processes
>>      invalid where intelligence intervenes?
>>
>> 1988 Nature 27 Oct. 779/2 Questions about the energy needed in
>>      measurement began with Maxwell's demon.
>> ...

For the word `daemon', the OED has this:

>> ...
>> Etymology: Probably an extended use of demon ....
>>
>> A program (or part of a program), esp. within a Unix system, which
>> runs in the background without intervention by the user, either
>> continuously or only when automatically activated by a particular
>> event or condition.  A distinction is sometimes made between the form
>> daemon, referring to a program on an operating system, and demon,
>> referring to a portion of a program, but the forms seem generally to
>> be used interchangeably, daemon being more usual.
>>
>> 1971 A. Bhushan Request for Comments (Network Working Group)
>>      (Electronic text) No. 114. 2 The cooperating processes may be
>>      `daemon' processes which `listen' to agreed-upon sockets, and
>>      follow the initial connection protocol.
>>
>> 1983 E. S. Raymond Hacker's Dict. 53 The printer daemon is just a
>>      program that is always running; it checks the special directory
>>      periodically, and whenever it finds a file there it prints it
>>      and then deletes it.
>>
>> 1989 DesignCenter ii. 41/3 The file server runs a standard set of
>>      HP-UX system and network daemons.
>>
>> 1992 New Scientist 18 Jan. 35/2 These programs, which could recognise
>>      simple patterns, were made up of several independent
>>      information-processing units, or `demons', and a `master
>>      demon'.
>>
>> 2002 N.Y. Times 7 Mar. d4/5 A mailer daemon installed on an e-mail
>>      system can respond to a piece of incorrectly addressed e-mail
>>      by generating an automated message to the sender that the
>>      message was undeliverable.
>> ...

	       ----------------------------------------

From The Hacker's Dictionary (1983), reproduced in the Emacs info node
Jargon, I find another `explanation' of daemon:

>> ...
>> :daemon: /day'mn/ or /dee'mn/ /n./  [from the mythological
>>    meaning, later rationalized as the acronym `Disk And Execution
>>    MONitor'] A program that is not invoked explicitly, but lies
>>    dormant waiting for some condition(s) to occur.  The idea is that
>>    the perpetrator of the condition need not be aware that a daemon is
>>    lurking (though often a program will commit an action only because
>>    it knows that it will implicitly invoke a daemon).  For example,
>>    under {{ITS}} writing a file on the {LPT} spooler's directory
>>    would invoke the spooling daemon, which would then print the file.
>>    The advantage is that programs wanting (in this example) files
>>    printed need neither compete for access to nor understand any
>>    idiosyncrasies of the {LPT}.  They simply enter their implicit
>>    requests and let the daemon decide what to do with them.  Daemons
>>    are usually spawned automatically by the system, and may either
>>    live forever or be regenerated at intervals.
>>
>>    Daemon and {demon} are often used interchangeably, but seem to
>>    have distinct connotations.  The term `daemon' was introduced to
>>    computing by {CTSS} people (who pronounced it /dee'mon/) and
>>    used it to refer to what ITS called a {dragon}.  Although the
>>    meaning and the pronunciation have drifted, we think this glossary
>>    reflects current (1996) usage.
>> ...

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

[TUHS] daemons are not to be exorcised

[Noel Chiappa]

    > From: Larry McVoy <lm at mcvoy.com>

    > Going forward, I wish that people tried to be simple as they tackle the
    > more complicated problems we have.

I have a couple of relevant quotations on my 'Some Computer-Related Lines'
page:

  "Deliberate complexity is the mark of an amateur. Elegant simplicity is the
  mark of a master."
	-- Unknown, quoted by Robert A. Crawford 

  "Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses
  remove it."
	-- Alan Perlis

  "The most reliable components are the ones you leave out." 
	-- Gordon Bell

(For software, the latter needs to be read as 'The most bug-free lines of
codqe are the ones you leave out', of course.)


I remember watching the people building the LISP machine, and thinking 'Wow,
that system is complex'. I eventually decided the problem was that they were
_too_ smart. They could understand, and retain in their minds, all that
complexity.

	Noel

[TUHS] daemons are not to be exorcised

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2782 bytes --]

On Wed, Mar 21, 2018 at 10:17 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Larry McVoy <lm at mcvoy.com>
>
>     > Going forward, I wish that people tried to be simple as they tackle
> the
>     > more complicated problems we have.
>
> I have a couple of relevant quotations on my 'Some Computer-Related Lines'
> page:
>
>   "Deliberate complexity is the mark of an amateur. Elegant simplicity is
> the
>   mark of a master."
>         -- Unknown, quoted by Robert A. Crawford
>
>   "Fools ignore complexity. Pragmatists suffer it. Some can avoid it.
> Geniuses
>   remove it."
>         -- Alan Perlis
>
>   "The most reliable components are the ones you leave out."
>         -- Gordon Bell
>
> (For software, the latter needs to be read as 'The most bug-free lines of
> code are the ones you leave out', of course.)
>
​Amen...​




>
>
> I remember watching the people building the LISP machine, and thinking
> 'Wow,
> that system is complex'. I eventually decided the problem was that they
> were
> _too_ smart. They could understand, and retain in their minds, all that
> ​ ​
> complexity.

​And therein lies another interesting paradox... smart people don't always
realize that ​
​their being "smarter than the average bear" as it were, means mortals are
unlikely to be able to understand what you are doing.  Or more importantly,
your might not be that 'smart' later.

I'll never forget a conversation with one of my officemates at Masscomp who
had come from Steve Ward's group at MIT, who I will not name.  But he is
one the smartest people I ever worked with and someone I have tremendous
respect.   CMU used to have a required SW Engineering course and one of the
things drilled into us was commenting (you can usually tell code I worked
on by the dyslexia in my comments - but I do try to leave bit crumbs).​

Anyway, said person never had a such a course.  He says to me -- "Well I
only comment things I did not understand."   I looked at him in awe and
said:  "'Fred' -  you are one of the smartest people I know, please put the
comments in there for the rest of us."

A bit later, he got cut by his own sword.  He had had to pick up a piece of
code he had written a long time before and of course the context that he
had had when he wrote it was by that time completely lost.  Guess what - he
could not understand what the code was doing [BTW:  The last time I saw
something he wrote, he was wonderful at writing comments].

To me, "keep it short, simple, but always explain your intentions in prose"
need to be the guiding lights for programmers.

Clem
ᐧ
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/abc132e1/attachment.html>

[TUHS] daemons are not to be exorcised

[Arthur Krewat]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]

On 3/21/2018 11:03 AM, Clem Cole wrote:
>
> To me, "keep it short, simple, but always explain your intentions in 
> prose" need to be the guiding lights for programmers.

It was instilled in me early on by my one and only mentor that someone 
that comes along later may have no idea what my code is doing. So 
comment. Even when it might be self-explanitory, comment anyway. This 
was on TOPS-10 back in the early 80's, usually MACRO-10 although I 
dabbled in ALGOL, SNOBOL, FORTRAN, etc.

When I look back at my own code, I can read the comments as the 
plot-line, so to speak, and the code itself just follows along.

I have noticed a lot of newer programmers these days that say 
(paraphrased): "Good code will explain itself" as a reason not to 
comment. Mostly C++ and Java programmers.

I call bullshit on that. Not commenting is lazy. There's no reason NOT 
to comment.

Most of my stuff has more comments byte-wise than real code. Something I 
wrote just yesterday as part of a much larger project:

// remove the UTF-8 BOM at the beginning of a line of text.
char bom[] = { 0xEF, 0xBB, 0xBF, 0 };                  // UTF-8 BOM
void remove_bom(char *str) {

     if (strncmp(str, bom, strlen(bom)) == 0) {         // can we find 
the BOM at the beginning of the line?
         strcpy(str, str + strlen(bom));             // yup, kill it.
     }
}

While that is definitely self-explanitory, I just can't help myself - 
and no, don't comment on my brazen assumptions of string length, or the 
fact that I assume it's UTF-8 - I've taken care of all of that 
elsewhere...  ;)

ak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/d7cca4d3/attachment.html>

[TUHS] daemons are not to be exorcised

[Paul Winalski]

On 3/21/18, Arthur Krewat <krewat at kilonet.net> wrote:
>
> It was instilled in me early on by my one and only mentor that someone
> that comes along later may have no idea what my code is doing. So
> comment. Even when it might be self-explanitory, comment anyway.

In my 40-year career as a programmer, I've more than once had that
someone who comes along later be myself.

I also apply what I call the Bus Principle.  If you get hit by a bus
and killed, one of your colleagues is going to have to take over your
work.  Give them a fighting chance with code comments, and maybe even
a design document for large or complex things.

> I have noticed a lot of newer programmers these days that say
> (paraphrased): "Good code will explain itself" as a reason not to
> comment. Mostly C++ and Java programmers.
>
> I call bullshit on that. Not commenting is lazy. There's no reason NOT
> to comment.

Amen to that!  Good comments are one of the things that distinguishes
Software Engineering from mere programming.

-Paul W.

[TUHS] daemons are not to be exorcised

[George Michaelson]

I think there's a middle ground. saying "this is a loop" is not
informative. saying "I did this as a loop because..." can be very
informative.

I think with short circuit evaluation and side-effects in C, this kind
of code is especially worth commenting: people need to remember the
right hand side of a complex set of expressions might actually not
have done anything.

Here at IETF a really cute corner-case of optimization-for-bug came
up. Somebody who thought they had worked out a given packet in UDP dns
messages always had a pair of specific chars 0x0c and 0xc0 in sequence
(or something) and coded for it, not realizing they were coding below
the outcome of a DNS label compression pattern which didn't always
hold. Sometimes, people code from faulty or incomplete information. So
this one, (for instance) would have been much better commented than
not.

It would have let the following people hit the coder with a thin whippy stick.

On Wed, Mar 21, 2018 at 5:28 PM, Paul Winalski <paul.winalski at gmail.com> wrote:
> On 3/21/18, Arthur Krewat <krewat at kilonet.net> wrote:
>>
>> It was instilled in me early on by my one and only mentor that someone
>> that comes along later may have no idea what my code is doing. So
>> comment. Even when it might be self-explanitory, comment anyway.
>
> In my 40-year career as a programmer, I've more than once had that
> someone who comes along later be myself.
>
> I also apply what I call the Bus Principle.  If you get hit by a bus
> and killed, one of your colleagues is going to have to take over your
> work.  Give them a fighting chance with code comments, and maybe even
> a design document for large or complex things.
>
>> I have noticed a lot of newer programmers these days that say
>> (paraphrased): "Good code will explain itself" as a reason not to
>> comment. Mostly C++ and Java programmers.
>>
>> I call bullshit on that. Not commenting is lazy. There's no reason NOT
>> to comment.
>
> Amen to that!  Good comments are one of the things that distinguishes
> Software Engineering from mere programming.
>
> -Paul W.

[TUHS] daemons are not to be exorcised

[Arthur Krewat]

On 3/21/2018 1:33 PM, George Michaelson wrote:
> I think there's a middle ground. saying "this is a loop" is not
> informative. saying "I did this as a loop because..." can be very
> informative.
Absolutely. Using my "comments as the plot" analogy, that would be like 
the main character in a movie saying "this is a chair" instead of "this 
is my dad's chair".

So much more meaning ;)

And bringing it back to UNIX, I remember reading here on this list that 
comments were sanitized, removing any humor. Anyone got any good 
examples of that?

[TUHS] daemons are not to be exorcised

[A. P. Garcia]

On Mar 21, 2018 12:51 PM, "Arthur Krewat" <krewat at kilonet.net> wrote:

On 3/21/2018 1:33 PM, George Michaelson wrote:

> I think there's a middle ground. saying "this is a loop" is not
> informative. saying "I did this as a loop because..." can be very
> informative.
>
Absolutely. Using my "comments as the plot" analogy, that would be like the
main character in a movie saying "this is a chair" instead of "this is my
dad's chair".

So much more meaning ;)

And bringing it back to UNIX, I remember reading here on this list that
comments were sanitized, removing any humor. Anyone got any good examples
of that?


Well, I remember many years ago seeing a comment in the Linux kernel to the
effect that the kernel would never be larger than 2 MB IIRC. Which to me is
kind of humorous in retrospect.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/2a9bcb35/attachment-0001.html>

[TUHS] daemons are not to be exorcised

[Paul Winalski]

On 3/21/18, George Michaelson <ggm at algebras.org> wrote:
>
> I think with short circuit evaluation and side-effects in C, this kind
> of code is especially worth commenting: people need to remember the
> right hand side of a complex set of expressions might actually not
> have done anything.
>
One thing that is always worth a comment is Perl regular expressions.
A prose description of what the regex is supposed to match can save
someone else a lot of time.

-Paul W.

[TUHS] daemons are not to be exorcised

[Larry McVoy]

On Wed, Mar 21, 2018 at 01:28:34PM -0400, Paul Winalski wrote:
> On 3/21/18, Arthur Krewat <krewat at kilonet.net> wrote:
> >
> > It was instilled in me early on by my one and only mentor that someone
> > that comes along later may have no idea what my code is doing. So
> > comment. Even when it might be self-explanitory, comment anyway.
> 
> In my 40-year career as a programmer, I've more than once had that
> someone who comes along later be myself.

Yep.  Someone once told me "any code that you wrote more than 6 months
ago might as well have been written by someone else.  So write it in a
way that you can debug it".

[TUHS] daemons are not to be exorcised

[Dave Horsfall]

On Wed, 21 Mar 2018, Larry McVoy wrote:

> Yep.  Someone once told me "any code that you wrote more than 6 months 
> ago might as well have been written by someone else.  So write it in a 
> way that you can debug it".

Yep, and I'm glad that I had bosses to whom I didn't have to explain why 
my comments were so voluminous.

And who first said "Write your code as though the next person to maintain 
it is a psychotic axe-wielding murderer who knows where you live"?  I've 
often thought that way (as the murderer I mean, not the murderee).

I'd name names, but he might be on this list...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] daemons are not to be exorcised

[WIlliam Cheswick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 449 bytes --]


> On Mar 21, 2018, at 1:28 PM, Paul Winalski <paul.winalski at gmail.com> wrote:
> 
> In my 40-year career as a programmer, I've more than once had that
> someone who comes along later be myself.

“Comments are love letters we write to our future selves.”
 - Jon Bentley

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/760a9e6e/attachment-0001.html>

[TUHS] daemons are not to be exorcised

[Arthur Krewat]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 345 bytes --]

On 3/21/2018 1:39 PM, WIlliam Cheswick wrote:
>
> “Comments are love letters we write to our future selves.”
>  - Jon Bentley

Truth be told, I sometimes get into a melancholy state, and go back to 
code I wrote decades ago just to go through the history section and 
remind myself why I got into this line of work in the first place.

ak

[TUHS] daemons are not to be exorcised

[Nemo]

On 21 March 2018 at 13:28, Paul Winalski <paul.winalski at gmail.com>
wrote (in part):
> I also apply what I call the Bus Principle.  If you get hit by a bus
> and killed, one of your colleagues is going to have to take over your
> work.  Give them a fighting chance with code comments, and maybe even
> a design document for large or complex things.

A manager insisted that everyone spend the last 15min of the day
writing down what was done that day on a sheet of paper and putting in
your desk drawer.  No one was run over by a bus but the paper became
the first thing many consulted next day (and the act of writing
consolidated thoughts -- something much lost today).

N.

[TUHS] daemons are not to be exorcised

[Larry McVoy]

On Wed, Mar 21, 2018 at 01:56:38PM -0400, Nemo wrote:
> On 21 March 2018 at 13:28, Paul Winalski <paul.winalski at gmail.com>
> wrote (in part):
> > I also apply what I call the Bus Principle.  If you get hit by a bus
> > and killed, one of your colleagues is going to have to take over your
> > work.  Give them a fighting chance with code comments, and maybe even
> > a design document for large or complex things.
> 
> A manager insisted that everyone spend the last 15min of the day
> writing down what was done that day on a sheet of paper and putting in
> your desk drawer.  No one was run over by a bus but the paper became
> the first thing many consulted next day (and the act of writing
> consolidated thoughts -- something much lost today).

I'd like a $repo/src/STATE file filled out at the end of my day.  Back in
the day I had a coworker that would do a 

	find /home/bk/lm -maxdepth 3 -name STATE -mtime -1

in the morning to see what I had been up to :)

The act of dumping what I was trying to do, what I had figured out so far,
just dumping state, frequently lead to the solution.  So it had the "bad"
effect of making me work longer to actually finish.

I've worked on problems in the kernel that were hard enough that it could
take me as much as 8 hours of thinking to get back to where I was yesterday.
The STATE file came out of that, it ramped me up faster.

--lm

[TUHS] daemons are not to be exorcised

[Dan Cross]

On Wed, Mar 21, 2018 at 1:28 PM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> On 3/21/18, Arthur Krewat <krewat at kilonet.net> wrote:
> > [...]
> > I call bullshit on that. Not commenting is lazy. There's no reason NOT
> > to comment.
>
> Amen to that!  Good comments are one of the things that distinguishes
> Software Engineering from mere programming.


Critical to that, however, is the adjective "good", as in "good comments."
Writing comments can be incredibly useful, but writing *good* comments is a
learned skill that requires judgement and taste.

Much ado is made nowadays about the "craft" of programming. I dislike this
analogy for a number of reasons, but there's no denying that good
programming has a craft element to it, and I claim that good commenting is
one of the harder of the craft skills to master. In particular, there *are*
good reasons NOT to comment something: the code is so obvious the comment
would just be a restatement of the manifestly evident, but with the added
visual clutter and cognitive load imposed by simply existing and the added
maintenance burden of being kept in sync. When I see a comment, I often
take it as an indication that something notable is happening: if the
comment is superfluous then I'm left wondering WHY it's there and what
about the code I'm missing. Similarly, comments must be maintained: my
experience is that out-of-date comments that have fallen out of sync with
the code are strictly a liability. Finding balance between the costs of
commenting and the positive benefits of comments takes time to develop.

When I was younger, I dressed somewhat better than I do now and when I was
in the Marines I once found myself in a social situation where it made
sense to wear a tweed jacket. Another Marine introduced me to the concept
of, "always, sometimes, never" vis which of the three buttons on the front
of my jacket to button: top button always, middle button sometimes, bottom
button never (whether this is good fashion advice or not is another
matter). I think that something analogous is true of writing good comments:

1. A comment should never simply parrot the code:  i++;  // Increment i.
2. A comment should sometimes explain *what* the code is doing.
3. A comment should always explain *why* the code is doing what it's doing.

Note that these are specific to comments, not to code: it does not follow,
for example, that a line or stanza of code should always be adorned with a
comment explaining why it exists: (think, `i++;  // Increment the array
index for the next iteration of the loop.` Ugh).

Btw, this is something I think that Unix did very well.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/29852f97/attachment.html>

[TUHS] daemons are not to be exorcised

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

On Wed, Mar 21, 2018 at 2:04 PM, Dan Cross <crossd at gmail.com> wrote:

>
> Critical to that, however, is the adjective "good", as in "good comments."
> Writing comments can be incredibly useful, but writing *good* comments is a
> learned skill that requires judgement and taste.
>
> ​....​
>
> 1. A comment should never simply parrot the code:  i++;  // Increment i.
> 2. A comment should sometimes explain *what* the code is doing.
> 3. A comment should always explain *why* the code is doing what it's doing.
>

i.e. there is a difference between: ​       i++;  // Increment i
*v.s.* the line: ​                      ptr->field++;  // ensure
reference count
stays sane

The former fails your first test, the second follows 2 & 3 as a note to my
future self that this is where I am doing the this piece of support work
(reference count maintenance).


Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/6803fa6c/attachment.html>

[TUHS] daemons are not to be exorcised

[Paul Winalski]

Regarding comments, when I'm modifying code to fix a bug I find it
useful to insert a comment that references the bug's number in the bug
tracking system.  It can help answer the question "why is this code
here?" for someone reading the code later on, and sometimes it can
prevent regressions being introduced.

To bring this back to Unix, how well have the various commenting
principles we've been discussing been adhered to in the code base?

-Paul W.