The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Were cron and at done at the same time? Or one before the other?
@ 2020-12-09  4:35 M Douglas McIlroy
  2020-12-09 15:40 ` Clem Cole
  0 siblings, 1 reply; 49+ messages in thread
From: M Douglas McIlroy @ 2020-12-09  4:35 UTC (permalink / raw)
  To: tuhs

This pair of commands exemplifies a weakness in the way Unix evolved.
Although it was the product of a shared vision, It was not a
product-oriented project. Unix commands work well together, but they
don't necessarily work alike.

It would be nice if identifiable families of commands had similar user
interfaces. However, cron and at were written by different
individuals, apparently with somewhat different tastes. Unix folks
were close colleagues, but had no organized design committee.

Time specs in cron and at are markedly different. A more consequential
example is data-field specs (or lack thereof) in sort, join, cut, comm
and uniq. The various specs were recognized as "wildly incongruent" in
a BUG remak. However there was no impetus for unification. To
paraphrase John Cocke (speaking about Fortran): one must understand
that Unix commands are not a logical language. They are a natural
language--in the sense that they developed by organic evolution, not
"intelligent design".

Doug

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-09  4:35 [TUHS] Were cron and at done at the same time? Or one before the other? M Douglas McIlroy
@ 2020-12-09 15:40 ` Clem Cole
  2020-12-09 15:46   ` Niklas Karlsson
                     ` (6 more replies)
  0 siblings, 7 replies; 49+ messages in thread
From: Clem Cole @ 2020-12-09 15:40 UTC (permalink / raw)
  To: M Douglas McIlroy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]

Amen Doug.

On Tue, Dec 8, 2020 at 11:36 PM M Douglas McIlroy <
m.douglas.mcilroy@dartmouth.edu> wrote:

> To paraphrase John Cocke (speaking about Fortran): one must understand
> that Unix commands are not a logical language. They are a natural
> language--in the sense that they developed by organic evolution, not
> "intelligent design".
>
But I offer a suggestion that another dimension that should be forgotten in
time scale and the economics within.

When things evolve they do so on different clocks that are not
necessarily linear.   *i.e. *what was 'better' (winning) today, but might
not be considered so tomorrow, however could yet prove otherwise sometime
later.  I use programming languages as a great example...   There was a
huge C vs Pascal debate, that C 'won' - but I've always said the rise of
C++ came from the Pascal folks that could say "C didn't win."  From the
ashes of C++ we have Java, Go, and Rust.

My point is that   "intelligent design" doesn't necessarily guarantee
goodness or for that matter,complete logical thinking.

My own take on this is what I call "Cole's Law"   *Simple economics always
beats sophisticated architecture.*
What you call *organic evolution* is what I think of what makes the *best
economic sense* for the user and that is a function of the time scale and
available resources at the time of creation/deployment.

Clem

[-- Attachment #2: Type: text/html, Size: 3318 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-09 15:40 ` Clem Cole
@ 2020-12-09 15:46   ` Niklas Karlsson
  2020-12-09 16:01   ` Bakul Shah
                     ` (5 subsequent siblings)
  6 siblings, 0 replies; 49+ messages in thread
From: Niklas Karlsson @ 2020-12-09 15:46 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

Den ons 9 dec. 2020 kl 16:42 skrev Clem Cole <clemc@ccc.com>:

>
> My point is that   "intelligent design" doesn't necessarily guarantee
> goodness or for that matter,complete logical thinking.
>
> My own take on this is what I call "Cole's Law"   *Simple economics
> always beats sophisticated architecture.*
> What you call *organic evolution* is what I think of what makes the *best
> economic sense* for the user and that is a function of the time scale and
> available resources at the time of creation/deployment.
>

Makes sense. Just consider Multics, or IBM's "Future System". "Intelligent
design" often becomes overambitious and elephantine.

That's not to say you don't want to put thought into your designs, but such
overambitious plans are a definite pitfall.

Niklas

[-- Attachment #2: Type: text/html, Size: 1770 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-09 15:40 ` Clem Cole
  2020-12-09 15:46   ` Niklas Karlsson
@ 2020-12-09 16:01   ` Bakul Shah
  2020-12-09 16:11     ` Clem Cole
  2020-12-14 20:28     ` Dave Horsfall
       [not found]   ` <CAC20D2PXZY9aWgDf-RknROs6JbKEUjzbQ2BRzfTgTR07pXni3g@mail.g mail.com>
                     ` (4 subsequent siblings)
  6 siblings, 2 replies; 49+ messages in thread
From: Bakul Shah @ 2020-12-09 16:01 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1578 bytes --]

please don’t blame c++ on pascal folks. stroustrup had nothing to do with pascal.  

> On Dec 9, 2020, at 7:41 AM, Clem Cole <clemc@ccc.com> wrote:
> 
> 
> Amen Doug.
> 
>> On Tue, Dec 8, 2020 at 11:36 PM M Douglas McIlroy <m.douglas.mcilroy@dartmouth.edu> wrote:
>> To paraphrase John Cocke (speaking about Fortran): one must understand
>> that Unix commands are not a logical language. They are a natural
>> language--in the sense that they developed by organic evolution, not
>> "intelligent design".
> But I offer a suggestion that another dimension that should be forgotten in time scale and the economics within.
> 
> When things evolve they do so on different clocks that are not necessarily linear.   i.e. what was 'better' (winning) today, but might not be considered so tomorrow, however could yet prove otherwise sometime later.  I use programming languages as a great example...   There was a huge C vs Pascal debate, that C 'won' - but I've always said the rise of C++ came from the Pascal folks that could say "C didn't win."  From the ashes of C++ we have Java, Go, and Rust. 
> 
> My point is that   "intelligent design" doesn't necessarily guarantee goodness or for that matter,complete logical thinking.
> 
> My own take on this is what I call "Cole's Law"   Simple economics always beats sophisticated architecture.
> What you call organic evolution is what I think of what makes the best economic sense for the user and that is a function of the time scale and available resources at the time of creation/deployment.
> 
> Clem
> 

[-- Attachment #2: Type: text/html, Size: 3731 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
       [not found]   ` <CAC20D2PXZY9aWgDf-RknROs6JbKEUjzbQ2BRzfTgTR07pXni3g@mail.g mail.com>
@ 2020-12-09 16:04     ` John Foust
  0 siblings, 0 replies; 49+ messages in thread
From: John Foust @ 2020-12-09 16:04 UTC (permalink / raw)
  To: tuhs

At 09:40 AM 12/9/2020, Clem Cole wrote:
>My own take on this is what I call "Cole's Law"Â  Â Simple economics always beats sophisticated architecture.

I thought that was finely sliced cabbage with a tart salad dressing.

- John


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-09 16:01   ` Bakul Shah
@ 2020-12-09 16:11     ` Clem Cole
  2020-12-09 17:05       ` Bakul Shah
  2020-12-14 20:28     ` Dave Horsfall
  1 sibling, 1 reply; 49+ messages in thread
From: Clem Cole @ 2020-12-09 16:11 UTC (permalink / raw)
  To: Bakul Shah; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]

Ah .. but all the Pascal folks got on the C++ bandwagon when it was clear C
had won.  Frankly, the death of C++ IMO was all the crap added too it, but
we have moved in COFF territory and off of Unix and Unix philosophy I think.

On Wed, Dec 9, 2020 at 11:01 AM Bakul Shah <bakul@iitbombay.org> wrote:

> please don’t blame c++ on pascal folks. stroustrup had nothing to do with
> pascal.
>
> On Dec 9, 2020, at 7:41 AM, Clem Cole <clemc@ccc.com> wrote:
>
> 
> Amen Doug.
>
> On Tue, Dec 8, 2020 at 11:36 PM M Douglas McIlroy <
> m.douglas.mcilroy@dartmouth.edu> wrote:
>
>> To paraphrase John Cocke (speaking about Fortran): one must understand
>> that Unix commands are not a logical language. They are a natural
>> language--in the sense that they developed by organic evolution, not
>> "intelligent design".
>>
> But I offer a suggestion that another dimension that should be forgotten
> in time scale and the economics within.
>
> When things evolve they do so on different clocks that are not
> necessarily linear.   *i.e. *what was 'better' (winning) today, but might
> not be considered so tomorrow, however could yet prove otherwise sometime
> later.  I use programming languages as a great example...   There was a
> huge C vs Pascal debate, that C 'won' - but I've always said the rise of
> C++ came from the Pascal folks that could say "C didn't win."  From the
> ashes of C++ we have Java, Go, and Rust.
>
> My point is that   "intelligent design" doesn't necessarily guarantee
> goodness or for that matter,complete logical thinking.
>
> My own take on this is what I call "Cole's Law"   *Simple economics
> always beats sophisticated architecture.*
> What you call *organic evolution* is what I think of what makes the *best
> economic sense* for the user and that is a function of the time scale and
> available resources at the time of creation/deployment.
>
> Clem
>
>

[-- Attachment #2: Type: text/html, Size: 4368 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-09 15:40 ` Clem Cole
                     ` (2 preceding siblings ...)
       [not found]   ` <CAC20D2PXZY9aWgDf-RknROs6JbKEUjzbQ2BRzfTgTR07pXni3g@mail.g mail.com>
@ 2020-12-09 16:40   ` Warner Losh
  2020-12-09 16:53     ` Jon Steinhart
  2020-12-09 16:58   ` Theodore Y. Ts'o
                     ` (2 subsequent siblings)
  6 siblings, 1 reply; 49+ messages in thread
From: Warner Losh @ 2020-12-09 16:40 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

On Wed, Dec 9, 2020 at 8:41 AM Clem Cole <clemc@ccc.com> wrote:

> Amen Doug.
>
> On Tue, Dec 8, 2020 at 11:36 PM M Douglas McIlroy <
> m.douglas.mcilroy@dartmouth.edu> wrote:
>
>> To paraphrase John Cocke (speaking about Fortran): one must understand
>> that Unix commands are not a logical language. They are a natural
>> language--in the sense that they developed by organic evolution, not
>> "intelligent design".
>>
> But I offer a suggestion that another dimension that should be forgotten
> in time scale and the economics within.
>
> When things evolve they do so on different clocks that are not
> necessarily linear.   *i.e. *what was 'better' (winning) today, but might
> not be considered so tomorrow, however could yet prove otherwise sometime
> later.  I use programming languages as a great example...   There was a
> huge C vs Pascal debate, that C 'won' - but I've always said the rise of
> C++ came from the Pascal folks that could say "C didn't win."  From the
> ashes of C++ we have Java, Go, and Rust.
>
> My point is that   "intelligent design" doesn't necessarily guarantee
> goodness or for that matter,complete logical thinking.
>
> My own take on this is what I call "Cole's Law"   *Simple economics
> always beats sophisticated architecture.*
> What you call *organic evolution* is what I think of what makes the *best
> economic sense* for the user and that is a function of the time scale and
> available resources at the time of creation/deployment.
>

I agree, but I thought Cole's Law was thinly sliced cabbage.

Warner

>
> Clem
>
>

[-- Attachment #2: Type: text/html, Size: 3923 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-09 16:40   ` Warner Losh
@ 2020-12-09 16:53     ` Jon Steinhart
  0 siblings, 0 replies; 49+ messages in thread
From: Jon Steinhart @ 2020-12-09 16:53 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Warner Losh writes:
>
> I agree, but I thought Cole's Law was thinly sliced cabbage.
>
> Warner

No, it's a song by Zero.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-09 15:40 ` Clem Cole
                     ` (3 preceding siblings ...)
  2020-12-09 16:40   ` Warner Losh
@ 2020-12-09 16:58   ` Theodore Y. Ts'o
  2020-12-09 19:58     ` Dan Cross
  2020-12-09 23:22     ` Bakul Shah
  2020-12-10  0:19   ` [TUHS] Cole's Slaw John Gilmore
  2020-12-12  2:56   ` [TUHS] Were cron and at done at the same time? Or one before the other? Dave Horsfall
  6 siblings, 2 replies; 49+ messages in thread
From: Theodore Y. Ts'o @ 2020-12-09 16:58 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

On Wed, Dec 09, 2020 at 10:40:19AM -0500, Clem Cole wrote:
> My point is that "intelligent design" doesn't necessarily guarantee
> goodness or for that matter,complete logical thinking.

There are some really great quotes, mostly from Linus, but I saw at
least one from Larry McVoy, here, on the subject of "Linux is all
about evolution, not intelligent design" here:

https://ipfs.io/ipfs/QmdA5WkDNALetBn4iFeSepHjdLGJdxPBwZyY47ir1bZGAK/comp/evolution.html

One of the quotes from Linus that is most pertinent for TUHS from the
above:

    > There was a overall architecture, from Dennis and Ken.

    Ask them. I'll bet you five bucks they'll agree with me, not with you.
    I've talked to both, but not really about this particular issue, so I
    might lose, but I think I've got the much better odds.

    If you want to see a system that was more thoroughly _designed_, you
    should probably point not to Dennis and Ken, but to systems like L4 and
    Plan-9, and people like Jochen Liedtk and Rob Pike.

    And notice how they aren't all that popular or well known? "Design" is
    like a religion - too much of it makes you inflexibly and unpopular.

    The very architecture of UNIX has very much been an evolution. Sure, there
    are some basic ideas, but basic ideas do not make a system.

    	     	   	      	    	     	 - Ted

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-09 16:11     ` Clem Cole
@ 2020-12-09 17:05       ` Bakul Shah
  2020-12-09 17:42         ` Dan Stromberg
  0 siblings, 1 reply; 49+ messages in thread
From: Bakul Shah @ 2020-12-09 17:05 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2278 bytes --]

Ah .. but I don’t know if they did! The implication that Pascal folks like complexity seems strange as Pascal is far simpler than C++ (not much larger than C) and C++ is no more type safe than C (both are less type safe than Pascal). Anyway I will stop now! 

> On Dec 9, 2020, at 8:11 AM, Clem Cole <clemc@ccc.com> wrote:
> 
> 
> Ah .. but all the Pascal folks got on the C++ bandwagon when it was clear C had won.  Frankly, the death of C++ IMO was all the crap added too it, but we have moved in COFF territory and off of Unix and Unix philosophy I think.
> 
>> On Wed, Dec 9, 2020 at 11:01 AM Bakul Shah <bakul@iitbombay.org> wrote:
>> please don’t blame c++ on pascal folks. stroustrup had nothing to do with pascal.  
>> 
>>>> On Dec 9, 2020, at 7:41 AM, Clem Cole <clemc@ccc.com> wrote:
>>>> 
>>> 
>>> Amen Doug.
>>> 
>>>> On Tue, Dec 8, 2020 at 11:36 PM M Douglas McIlroy <m.douglas.mcilroy@dartmouth.edu> wrote:
>>>> To paraphrase John Cocke (speaking about Fortran): one must understand
>>>> that Unix commands are not a logical language. They are a natural
>>>> language--in the sense that they developed by organic evolution, not
>>>> "intelligent design".
>>> But I offer a suggestion that another dimension that should be forgotten in time scale and the economics within.
>>> 
>>> When things evolve they do so on different clocks that are not necessarily linear.   i.e. what was 'better' (winning) today, but might not be considered so tomorrow, however could yet prove otherwise sometime later.  I use programming languages as a great example...   There was a huge C vs Pascal debate, that C 'won' - but I've always said the rise of C++ came from the Pascal folks that could say "C didn't win."  From the ashes of C++ we have Java, Go, and Rust. 
>>> 
>>> My point is that   "intelligent design" doesn't necessarily guarantee goodness or for that matter,complete logical thinking.
>>> 
>>> My own take on this is what I call "Cole's Law"   Simple economics always beats sophisticated architecture.
>>> What you call organic evolution is what I think of what makes the best economic sense for the user and that is a function of the time scale and available resources at the time of creation/deployment.
>>> 
>>> Clem
>>> 

[-- Attachment #2: Type: text/html, Size: 4964 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-09 17:05       ` Bakul Shah
@ 2020-12-09 17:42         ` Dan Stromberg
  2020-12-09 23:46           ` Nemo Nusquam
  0 siblings, 1 reply; 49+ messages in thread
From: Dan Stromberg @ 2020-12-09 17:42 UTC (permalink / raw)
  To: Bakul Shah; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

On Wed, Dec 9, 2020 at 9:08 AM Bakul Shah <bakul@iitbombay.org> wrote:

> Ah .. but I don’t know if they did! The implication that Pascal folks like
> complexity seems strange as Pascal is far simpler than C++ (not much larger
> than C) and C++ is no more type safe than C (both are less type safe than
> Pascal). Anyway I will stop now!
>

I was one of the people who happily left Pascal behind to move to C.  But
in retrospect, I think the computing world would've been better off with
Pascal, modified slightly to allow passing variable-length arrays (like
TurboPascal).

I never did make the move to C++ - I've written only a little code in it.
Instead, when a lot of people were moving from C to C++ or Perl, I fished
around and hit upon a little-known language called Python (OCaml was runner
up).  My management was practically nonexistent back then, so no one told
me "No, use what everyone else is using!"

[-- Attachment #2: Type: text/html, Size: 1345 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-09 16:58   ` Theodore Y. Ts'o
@ 2020-12-09 19:58     ` Dan Cross
  2020-12-09 20:30       ` Will Senn
  2020-12-13  1:07       ` Theodore Y. Ts'o
  2020-12-09 23:22     ` Bakul Shah
  1 sibling, 2 replies; 49+ messages in thread
From: Dan Cross @ 2020-12-09 19:58 UTC (permalink / raw)
  To: Theodore Y. Ts'o; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 4829 bytes --]

On Wed, Dec 9, 2020 at 12:07 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:

> On Wed, Dec 09, 2020 at 10:40:19AM -0500, Clem Cole wrote:
> > My point is that "intelligent design" doesn't necessarily guarantee
> > goodness or for that matter,complete logical thinking.
>
> There are some really great quotes, mostly from Linus, but I saw at
> least one from Larry McVoy, here, on the subject of "Linux is all
> about evolution, not intelligent design" here:
>
>
> https://ipfs.io/ipfs/QmdA5WkDNALetBn4iFeSepHjdLGJdxPBwZyY47ir1bZGAK/comp/evolution.html
>
> One of the quotes from Linus that is most pertinent for TUHS from the
> above:
>
>     > There was a overall architecture, from Dennis and Ken.
>
>     Ask them. I'll bet you five bucks they'll agree with me, not with you.
>

Oh golly. Linus sure does have a special way of communicating.

    I've talked to both, but not really about this particular issue, so I
>     might lose, but I think I've got the much better odds.
>

If I understand the context here, it's that Linus is arguing against the
sort of large-scale architectural "design" that plagues software projects
that employ, say, the waterfall method, arguing in favor of organic
evolution for Linux development. I guess that's fine, but evolution almost
always favors a local maxima, and I don't think that's optimal in an
absolute sense. But I also don't know another way to do it that doesn't get
bogged down in the pursuit of perfection; it may be a necessary survival
trait.

I think that's a slightly disingenuous reading of what he's replying to,
though; by the time Linus started working on Linux, there was a pretty
well-defined Unix architecture in place that he was able to copy, very
successfully. Sure, the details are up to the implementer, but to suggest
that there wasn't a framework for his thinking about what Linux would look
like just isn't true.


>     If you want to see a system that was more thoroughly _designed_, you
>     should probably point not to Dennis and Ken, but to systems like L4 and
>     Plan-9, and people like Jochen Liedtk and Rob Pike.
>

I'm not sure I would agree with this assessment about either L4 or Plan 9.
Both evolved greatly over their lives, and both continue to evolve (though
plan9's evolution is greatly diminished).

    And notice how they aren't all that popular or well known? "Design" is
>     like a religion - too much of it makes you inflexibly and unpopular.
>

That's a terrible metric.

I submit that neither of those systems were created with the explicit goal
to become "popular", and the claim of inflexibility is unwarranted. Within
their domain, that is as research systems, both are quite well known and
remain highly influential.

This is a common but annoying line of thought in the computer world:
because something is useful and popular, it is good. My first car was a
1985 AMC Eagle; it was undeniably useful. It may have even been moderately
popular at one point. But damn it was an awful car.

Linux is undeniably useful and it's arguably the most popular operating
system in the world. And parts of it are really, really good. But simply
put, that doesn't mean that its evolutionary path has landed in an
inherently good place.

To circle back to plan 9 for a moment, this was something that the open
source folks who found their way to 9fans just couldn't grok. The answer to
the question, "why don't you do all this work to support (emacs|a web
browser|a C++ compiler|whatever du jour)?" was, "because there's little
inherent research value in doing that, and this is a research system." That
it was also a workaday system for a handful of folks was incidental; the
goal wasn't world domination, it was advancing research and providing a
comfortable environment for that work. Linus's response exemplifies this
lack of understanding. (Disclaimer: I was very much an outsider looking in
there, but it seems clear enough in retrospect.)

    The very architecture of UNIX has very much been an evolution. Sure,

    there are some basic ideas, but basic ideas do not make a system.
>

And yet, by the time that Linus started work on Linux, Unix already was a
system and had been for 20 years.

At the Unix 50th event at the LCM+L, Mary Ann and I spent a little time
playing around with the original 7th Edition on a simulator, trying to
write simple programs in B. There was certainly familiarity there, but it
was simultaneously very foreign; the system was recognizable as an
ancestor, but one very far back on the evolutionary timeline. If anything,
changes due to Linux's evolution from its early days are far less
pronounced, or perhaps I should say has been much more internally focused
(I recognize that the kernel sources are unrecognizable from what Linux was
putting onto Finnish FTP sites in 1991...).

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 6611 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-09 19:58     ` Dan Cross
@ 2020-12-09 20:30       ` Will Senn
  2020-12-13  1:07       ` Theodore Y. Ts'o
  1 sibling, 0 replies; 49+ messages in thread
From: Will Senn @ 2020-12-09 20:30 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 1783 bytes --]

On 12/9/20 1:58 PM, Dan Cross wrote:
> On Wed, Dec 9, 2020 at 12:07 PM Theodore Y. Ts'o <tytso@mit.edu 
> <mailto:tytso@mit.edu>> wrote:
>
>     On Wed, Dec 09, 2020 at 10:40:19AM -0500, Clem Cole wrote:
>     > My point is that "intelligent design" doesn't necessarily guarantee
>     > goodness or for that matter,complete logical thinking.
>
>     There are some really great quotes, mostly from Linus, but I saw at
>     least one from Larry McVoy, here, on the subject of "Linux is all
>     about evolution, not intelligent design" here:
>
>     https://ipfs.io/ipfs/QmdA5WkDNALetBn4iFeSepHjdLGJdxPBwZyY47ir1bZGAK/comp/evolution.html
>     <https://ipfs.io/ipfs/QmdA5WkDNALetBn4iFeSepHjdLGJdxPBwZyY47ir1bZGAK/comp/evolution.html>
>
>     One of the quotes from Linus that is most pertinent for TUHS from the
>     above:
>
>         > There was a overall architecture, from Dennis and Ken.
>
>         Ask them. I'll bet you five bucks they'll agree with me, not
>     with you.
>
>
Ugh! Seriously, evolution vs design? Implying that software can result 
from stochastic processes (an oxymoron, if ever there was one), is 
unlikely. These are semantic gyrations. Unix, was designed... back of a 
napkin, maybe, but it didn't appear out of the primordial ooze. It came 
out of an ordered mind, was realized, was revised and revised again, but 
always guided by an ordered intellect. That said, the use of the word 
evolution to refer to the gradual change of something into something 
else over time (another semantic gyration) certainly applies and I might 
refer the casual reader to Ritchie's article of similar title, The 
Evolution of the UNIX Time-Sharing System, as a great example of this 
use. Other than this tenuous connection, I'd call this COFF material.

Will

[-- Attachment #2: Type: text/html, Size: 3199 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-09 16:58   ` Theodore Y. Ts'o
  2020-12-09 19:58     ` Dan Cross
@ 2020-12-09 23:22     ` Bakul Shah
  2020-12-09 23:44       ` Steffen Nurpmeso
  1 sibling, 1 reply; 49+ messages in thread
From: Bakul Shah @ 2020-12-09 23:22 UTC (permalink / raw)
  To: Theodore Y. Ts'o; +Cc: The Eunuchs Hysterical Society

On Dec 9, 2020, at 9:06 AM, Theodore Y. Ts'o <tytso@mit.edu> wrote:
> 
> If you want to see a system that was more thoroughly _designed_, you
>   should probably point not to Dennis and Ken, but to systems like L4 and
>   Plan-9, and people like Jochen Liedtk and Rob Pike.
> 
>   And notice how they aren't all that popular or well known? "Design" is
>   like a religion - too much of it makes you inflexibly and unpopular.

I recently read an article that says in biology the “neutral
theory” (random chance has a profound effect on genetics and
evolution) is much more accepted now than Darwin & Wallace’s
“Principle of Natural Selection” (survival of the fittest).
This seems to apply here as well. Seems popularity has more
to do with being in the right place at the right time. Both
Plan9 & L4 are certainly more flexible.

IMHO the “religion” we are suffering from is "speed" or
rather too much attention to premature optimization in the
small. Each layer may be efficient but too many layers get
used so at the system level things are much worse: slower and
so complex that no one person understands the system. While
h/w performance and capacity has increased by orders of
magnitude, s/w has frittered away most of it. This religion
(including use of unsafe languages like C) has been largely
responsible for most of the vulnerabilities. We end up using
containers and virtual machines (VMs) to try counter these
vulnerabilities. VMs are a sledgehammer that wouldn’t be
required for isolation if all the user s/w ran on a
secure-by-design kernel (or hardware). Note that even the h/w
features vulnerable to security attacks were put in to improve
performance.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-09 23:22     ` Bakul Shah
@ 2020-12-09 23:44       ` Steffen Nurpmeso
  2020-12-09 23:51         ` Steffen Nurpmeso
  0 siblings, 1 reply; 49+ messages in thread
From: Steffen Nurpmeso @ 2020-12-09 23:44 UTC (permalink / raw)
  To: Bakul Shah; +Cc: The Eunuchs Hysterical Society

Bakul Shah wrote in
 <E204EAE4-3D80-4774-BC62-CD6678EF884B@iitbombay.org>:
 |On Dec 9, 2020, at 9:06 AM, Theodore Y. Ts'o <tytso@mit.edu> wrote:
 |> 
 |> If you want to see a system that was more thoroughly _designed_, you
 |>   should probably point not to Dennis and Ken, but to systems like L4 and
 |>   Plan-9, and people like Jochen Liedtk and Rob Pike.
 |> 
 |>   And notice how they aren't all that popular or well known? "Design" is
 |>   like a religion - too much of it makes you inflexibly and unpopular.
 |
 |I recently read an article that says in biology the “neutral
 |theory” (random chance has a profound effect on genetics and
 |evolution) is much more accepted now than Darwin & Wallace’s

Eh.  What these guys want is to push through "green" genetics with
massive lobby work.  Your head is a toilet and those masses of
lobbyists throw their diarrhoea on to you regardless.
"Indifference has won won won".

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-09 17:42         ` Dan Stromberg
@ 2020-12-09 23:46           ` Nemo Nusquam
  0 siblings, 0 replies; 49+ messages in thread
From: Nemo Nusquam @ 2020-12-09 23:46 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 778 bytes --]

On 12/09/20 12:42, Dan Stromberg wrote:
> On Wed, Dec 9, 2020 at 9:08 AM Bakul Shah <bakul@iitbombay.org 
> <mailto:bakul@iitbombay.org>> wrote:
>
>     Ah .. but I don’t know if they did! The implication that Pascal
>     folks like complexity seems strange as Pascal is far simpler than
>     C++ (not much larger than C) and C++ is no more type safe than C
>     (both are less type safe than Pascal). Anyway I will stop now!
>
>
> I was one of the people who happily left Pascal behind to move to C.  
> But in retrospect, I think the computing world would've been better 
> off with Pascal, modified slightly to allow passing variable-length 
> arrays (like TurboPascal).

As Wirth wrote, in retrospect he should have called it Pascal-2, not 
Modula-2.  [COFF, COFF]

N.

[-- Attachment #2: Type: text/html, Size: 1669 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-09 23:44       ` Steffen Nurpmeso
@ 2020-12-09 23:51         ` Steffen Nurpmeso
  0 siblings, 0 replies; 49+ messages in thread
From: Steffen Nurpmeso @ 2020-12-09 23:51 UTC (permalink / raw)
  To: Bakul Shah; +Cc: The Eunuchs Hysterical Society

Steffen Nurpmeso wrote in
 <20201209234435.CmOyp%steffen@sdaoden.eu>:
 |Bakul Shah wrote in
 | <E204EAE4-3D80-4774-BC62-CD6678EF884B@iitbombay.org>:
 ||On Dec 9, 2020, at 9:06 AM, Theodore Y. Ts'o <tytso@mit.edu> wrote:
 ||> 
 ||> If you want to see a system that was more thoroughly _designed_, you
 ||>   should probably point not to Dennis and Ken, but to systems like \
 ||>   L4 and
 ||>   Plan-9, and people like Jochen Liedtk and Rob Pike.
 ||> 
 ||>   And notice how they aren't all that popular or well known? "Design" is
 ||>   like a religion - too much of it makes you inflexibly and unpopular.
 ||
 ||I recently read an article that says in biology the “neutral
 ||theory” (random chance has a profound effect on genetics and
 ||evolution) is much more accepted now than Darwin & Wallace’s
 |
 |Eh.  What these guys want is to push through "green" genetics with
 |massive lobby work.  Your head is a toilet and those masses of
 |lobbyists throw their diarrhoea on to you regardless.
 |"Indifference has won won won".

Of course: i have no idea, please listen to the specialists who
know.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Cole's Slaw
  2020-12-09 15:40 ` Clem Cole
                     ` (4 preceding siblings ...)
  2020-12-09 16:58   ` Theodore Y. Ts'o
@ 2020-12-10  0:19   ` John Gilmore
  2020-12-10  0:29     ` Larry McVoy
  2020-12-10  1:49     ` John Cowan
  2020-12-12  2:56   ` [TUHS] Were cron and at done at the same time? Or one before the other? Dave Horsfall
  6 siblings, 2 replies; 49+ messages in thread
From: John Gilmore @ 2020-12-10  0:19 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

Clem Cole <clemc@ccc.com> wrote:
> My own take on this is what I call "Cole's Law" Simple economics
> always beats sophisticated architecture.

I'm with you, Clem!

That certainly worked for closing the Digital Divide.  Some suggested
allocating billions in tax dollars to subsidize the un-networked in the
1990s and 2000's.  Instead we mostly just waited a few years.
Semiconductor economics plus consumer behavior (demand rises very
quickly as prices drop, which provides economies of scale) solve most of
the problem for you.  (And in the 2020s Elon Musk and others have likely
accumulated enough capital and tech to solve the Last 500 Mile problem
-- aiming the dish straight up and to the horizons -- for rural and
maritime digital divide issues.)

Cole's Law has worked similarly for farm efficiency.  Farms in 2020 are
many times as efficient, on average, as they were 40 years ago, counting
all the inputs (water, energy, land, human time, fertilizer, etc) and
the outputs (food and waste products).  That's why you can get whole
cooked chickens for $8 at your local grocery, as just one example.  That
was not driven by detailed and complicated environmental regulations, or
farm subsidies, but by straightforward economics.  The more efficient
producers drove out, or bought up, or trained, the inefficient ones.
Information flowed from high efficiency farms to low efficiency ones,
resources flowed the other way.  Going back 140 years, it used to take
50% of the population to grow the food for 100% of us; now it takes less
than 2% of the population.  The US now has net farmland going back to
wilderness every year, because we feed ourselves and the world with less
land than it took last year.

It also worked for scaling up the Internet.  Not just from a few
federally supported fat slow regionals and one skinny backbone, to
thousands of ISP's (each of whom was self-supporting from customers, so
their income would scale with the demand).  Also worked for scaling to
higher and higher bandwidths, riding both the Moore's Law economics of
computation, and also the fiber optic economics of materials science and
semiconductor laser/receiver evolution.  Rather than complex
systemantics around limiting, capping, scheduling, reserving, or
otherwise restricting offered traffic, just cheaply make more headroom.
Move everything to higher frequencies (including infrared light in
fibers, and GHz in radio).  Oops, a pandemic that scales up your
traffic by 50% in a month and needs realtime latency for most of it?  No
problem, the economics caused us to build networks that handled that.

(BTW, why is your home network still using 1-gigabit Ethernet, when
10-gig Ethernet cards are $100, cat6 or 6a cables cost almost the same
as cat5, and 10GBASE-T switches are a few hundred dollars?)

Humans tend to make poor decisions about exponential functions that go
on for decades, because in evolution we so seldom saw that happen.  But
we're in the middle of one now, and it as much an exponential function
in *economics* as it is in *technology*.

	John
	




^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Cole's Slaw
  2020-12-10  0:19   ` [TUHS] Cole's Slaw John Gilmore
@ 2020-12-10  0:29     ` Larry McVoy
  2020-12-10  0:53       ` Erik E. Fair
  2020-12-12 21:11       ` Dave Horsfall
  2020-12-10  1:49     ` John Cowan
  1 sibling, 2 replies; 49+ messages in thread
From: Larry McVoy @ 2020-12-10  0:29 UTC (permalink / raw)
  To: John Gilmore; +Cc: The Eunuchs Hysterical Society

On Wed, Dec 09, 2020 at 04:19:06PM -0800, John Gilmore wrote:
> (BTW, why is your home network still using 1-gigabit Ethernet, when
> 10-gig Ethernet cards are $100, cat6 or 6a cables cost almost the same
> as cat5, and 10GBASE-T switches are a few hundred dollars?)

Because my ISP is below 100Mbit.   And gigabit is fast enough for doing
backups, which is the only time I care about performance.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Cole's Slaw
  2020-12-10  0:29     ` Larry McVoy
@ 2020-12-10  0:53       ` Erik E. Fair
  2020-12-10  3:10         ` George Michaelson
  2020-12-12 21:11       ` Dave Horsfall
  1 sibling, 1 reply; 49+ messages in thread
From: Erik E. Fair @ 2020-12-10  0:53 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

I bet your backups across the gigabit switch to your NAS are (small) incrementals.

You'll care about having 10gigE when you try a restore from backup.

We have a very persistent problem with storage capacity versus I/O bandwidth, which I metaphor as "swimming pools of data, which we fill & drain with garden hoses." How many terabytes of stable storage do you have at home?

Further, LANs have always lagged local I/O bandwidth (across PCI, PCIe, etc), independent of the nastiness introduced by latency and less-than-ideal data transfer protocols. Unix "diskless" workstations were only tolerable because the disks were still expensive and there were good reasons to share.

	Erik

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Cole's Slaw
  2020-12-10  0:19   ` [TUHS] Cole's Slaw John Gilmore
  2020-12-10  0:29     ` Larry McVoy
@ 2020-12-10  1:49     ` John Cowan
  2020-12-10  2:12       ` Jon Steinhart
  1 sibling, 1 reply; 49+ messages in thread
From: John Cowan @ 2020-12-10  1:49 UTC (permalink / raw)
  To: John Gilmore; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

On Wed, Dec 9, 2020 at 7:19 PM John Gilmore <gnu@toad.com> wrote:

That certainly worked for closing the Digital Divide.  Some suggested
> allocating billions in tax dollars to subsidize the un-networked in the
> 1990s and 2000's.  Instead we mostly just waited a few years.
> Semiconductor economics plus consumer behavior (demand rises very
> quickly as prices drop, which provides economies of scale) solve most of
> the problem for you.
>

Not quite yet.  As of 2018, which is the latest data I can find, only 73%
of U.S. households have 10 Mbps download speed or better, and only 46% have
100 Mbps service or better.  If you look at the lowest quartile of
household incomes, the figures are 33% and 18% respectively.  (You want
adoption figures, not deployment figures.)  Wiring up the whole country is
fine, but if people won't or can't use it, it does little good.

On Wed, Dec 9, 2020 at 7:53 PM Erik E. Fair <fair-tuhs@netbsd.org> wrote:

 How many terabytes of stable storage do you have at home?
>

None at all, unless you count physical books.  I don't bother with home
backups because they don't provide disaster recovery: I'm not going to be
thinking about grabbing a hard disk on my way out the door if there's a
fire or flood.  Instead, I keep about 186 GB in an S3 bucket (a fair amount
of that is redundant, but it doesn't make sense for me to spend time
deduplicating files).  I also have about 4 GB in two Google accounts.
 Essentially all of that is text/plain, text/html, or application/pdf.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
Monday we watch-a Firefly's house, but he no come out.  He wasn't home.
Tuesday we go to the ball game, but he fool us.  He no show up.  Wednesday
he
go to the ball game, and we fool him.  We no show up.  Thursday was a
double-header.  Nobody show up.  Friday it rained all day.  There was no
ball
game, so we stayed home and we listened to it on-a the radio.  --Chicolini

[-- Attachment #2: Type: text/html, Size: 3853 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Cole's Slaw
  2020-12-10  1:49     ` John Cowan
@ 2020-12-10  2:12       ` Jon Steinhart
  0 siblings, 0 replies; 49+ messages in thread
From: Jon Steinhart @ 2020-12-10  2:12 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

John Cowan writes:
>
> That certainly worked for closing the Digital Divide.  Some suggested
> > allocating billions in tax dollars to subsidize the un-networked in the
> > 1990s and 2000's.  Instead we mostly just waited a few years.
> > Semiconductor economics plus consumer behavior (demand rises very
> > quickly as prices drop, which provides economies of scale) solve most of
> > the problem for you.
> >
>
> Not quite yet.  As of 2018, which is the latest data I can find, only 73%
> of U.S. households have 10 Mbps download speed or better, and only 46% have
> 100 Mbps service or better.  If you look at the lowest quartile of
> household incomes, the figures are 33% and 18% respectively.  (You want
> adoption figures, not deployment figures.)  Wiring up the whole country is
> fine, but if people won't or can't use it, it does little good.

This is not a really TUHS topic.  As one of those people who does not have
decent internet service and am still waiting I'd be happy to see some money
spent to broaden availability.  This is not being a matter of waiting years,
it's a matter of waiting decades so far.  Access is an equity issue as it's
essential for everything from participating in government, schooling, and
almost every other aspect of life today.  Maybe people with good service are
willing to have everyone else wait but IMHO society isn't well served that way.

Jon

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Cole's Slaw
  2020-12-10  0:53       ` Erik E. Fair
@ 2020-12-10  3:10         ` George Michaelson
  0 siblings, 0 replies; 49+ messages in thread
From: George Michaelson @ 2020-12-10  3:10 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

I deployed cheap switches, to try and reduce contention on the WiFi
segment in a 3bed flat. I suspect, switching is *slower* than good
quality 4/5G. I deployed cheap unmanaged switches. I think I may need
to re-consider. (it may be slower than good quality 5gz WIFi but I
felt not, lots of concrete, so I went cables in walls. Professionally
installed cables too)

old cheap switches have high port speed, but low cross-backplane
bandwidth. They basically don't do what they say on the label although
I have no proof, my observation is that 100mbit is rarely achieved on
a cheap switching backplane. I think most people won't notice. If you
need to do the full-disk restore, or stream 4K at the same time as
play some call-of-duty *and* do a full-disk streaming restore, I think
you can destroy your cheap home switch quickly. I have been prepping a
ZFS filestore and I calculate I'm getting 30mbit-sec end-to-end from
300mbit capable backplane hosts. The port speeds are gig. The actual
capability once you get over the Raspberry Pi USB3 is a LOT less. (the
receiver is a Pi4 with 8GB of memory, it should *not* be disk I/O
bound)

my various OSX Macs can do roaring speeds if you back-to-back connect
them. Put them into the switching stuff, it drops off really quickly
to boringly slow speeds.

If you go out the fibre router to the public network, I think their
contention model remains interesting: Stuff is being done in layer 2
to manage your bandwidth and the fibre which is capable of gig, is
probably doing bizarre things to pretend to be slower. Forced
bit-drop, random drop, long stalls. The framing at layer2 is really
bizarre. they can do a LOT in layer 2, they don't talk about. we're
all some kind of PPPo<something> inside this, which feels pretty meh.
Why did it have to be like this?

Economies which (unlike Australia) don't do bandwidth limit for
pricing disfunction, probably are saying :what do you mean: at this
point. (The UK, you can get true gig to the home. Parts of the USA
likewise. Lots of europe likewise. Here in Oz, although the bearer is
capable, you can't afford the price they want to charge because they'd
doing ROI sums to pay back $50b of spend, as quickly as possible)

If your router is running the Broadcom chipset most of them are built
around, Its switch is not really very big, in buffer space.  My R7000
is a  Broadcom BCM4709A0 and I don't think its doing very well.

So, I'm dying inside because this is highly contestable FUD. If
somebody with shares in the vendors chipset can tell me "you're just
wrong' I'd believe them but my experience from the field is, white box
domestic switches, and home routers, simply can't "do" full-bore gig
on multiple paths across the switch at once. Ubiquity and other good
vendors? Probably fine. Hell, for all I know, even Mikrotik might be
ok, I've only ever had their toss-away freebies from conference Schwag
and it was cool to have a box the size of a packet of cigarettes which
run BGP, but they felt pretty slow (they even do portspan. amazing
stuff)

-G


On Thu, Dec 10, 2020 at 10:53 AM Erik E. Fair <fair-tuhs@netbsd.org> wrote:
>
> I bet your backups across the gigabit switch to your NAS are (small) incrementals.
>
> You'll care about having 10gigE when you try a restore from backup.
>
> We have a very persistent problem with storage capacity versus I/O bandwidth, which I metaphor as "swimming pools of data, which we fill & drain with garden hoses." How many terabytes of stable storage do you have at home?
>
> Further, LANs have always lagged local I/O bandwidth (across PCI, PCIe, etc), independent of the nastiness introduced by latency and less-than-ideal data transfer protocols. Unix "diskless" workstations were only tolerable because the disks were still expensive and there were good reasons to share.
>
>         Erik

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-09 15:40 ` Clem Cole
                     ` (5 preceding siblings ...)
  2020-12-10  0:19   ` [TUHS] Cole's Slaw John Gilmore
@ 2020-12-12  2:56   ` Dave Horsfall
  2020-12-12 19:10     ` scj
  6 siblings, 1 reply; 49+ messages in thread
From: Dave Horsfall @ 2020-12-12  2:56 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

On Wed, 9 Dec 2020, Clem Cole wrote:

> My point is that   "intelligent design" doesn't necessarily guarantee 
> goodness or for that matter,complete logical thinking.

Don't mention "intelligent design" in my hearing; it's just a fad
term for creation theory...

Look at Unix, for example :-)  It didn't so much spring from the brow of 
Zeus i.e. Ken and Dennis, but has since evolved over decades (and it's 
still recognisable as Unix).

-- Dave, using Unix since Edition 5

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-12  2:56   ` [TUHS] Were cron and at done at the same time? Or one before the other? Dave Horsfall
@ 2020-12-12 19:10     ` scj
  0 siblings, 0 replies; 49+ messages in thread
From: scj @ 2020-12-12 19:10 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

As the inventor of "at", I can tell you that cron existed for quite some 
time, but was little used.  An arcane set of manipulations was required 
to get things to run, and there was little demand.   But there were a 
bunch of us all using the same PDP-11, and I wanted to add a job to run 
at 3AM that would be a bit of CPU hog.  I struggled and finally got 
something to work.  And thinking about it, I realized that what I really 
wanted to say was
    at 3am command-line
I made a shell script that did the bare minimum and advertised it on 
motd.  Within a day or two, Dennis grabbed it and made sure that the job 
would run in the proper directory with the correct permissions, and 
otherwise behave the way I wanted it to.

As many of you know, the rule with Unix was "you can touch anything, but 
if you change it, you own it."  This was a great way to turn arguments 
into progress.  I think I "owned" at for at most two days.  I had a 
similar experience with
spell--I think my ownership of spell lasted about 2 weeks.

In both cases, I was delighted to provide the "sperm of the idea" and 
let someone else carry and deliver the baby.

---


On 2020-12-11 18:56, Dave Horsfall wrote:
> On Wed, 9 Dec 2020, Clem Cole wrote:
> 
>> My point is that   "intelligent design" doesn't necessarily guarantee 
>> goodness or for that matter,complete logical thinking.
> 
> Don't mention "intelligent design" in my hearing; it's just a fad
> term for creation theory...
> 
> Look at Unix, for example :-)  It didn't so much spring from the brow
> of Zeus i.e. Ken and Dennis, but has since evolved over decades (and
> it's still recognisable as Unix).
> 
> -- Dave, using Unix since Edition 5

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Cole's Slaw
  2020-12-10  0:29     ` Larry McVoy
  2020-12-10  0:53       ` Erik E. Fair
@ 2020-12-12 21:11       ` Dave Horsfall
  1 sibling, 0 replies; 49+ messages in thread
From: Dave Horsfall @ 2020-12-12 21:11 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Wed, 9 Dec 2020, Larry McVoy wrote:

> Because my ISP is below 100Mbit.  And gigabit is fast enough for doing 
> backups, which is the only time I care about performance.

Indeed.  I don't do video streaming (I have something called "advert-free 
free to air television") but I do a lot of software updates, so I care 
more about download limits than speed.

As a result, my current plan is unlimited download bytes, but my download 
speed is 50Mb/s; I can wait (my MacBook's updates happen overnight 
anyway)...

My (wireless) LAN is around 250MB/sec; I don't care about speed so much as 
capacity.

-- Dave

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-09 19:58     ` Dan Cross
  2020-12-09 20:30       ` Will Senn
@ 2020-12-13  1:07       ` Theodore Y. Ts'o
  2020-12-13  1:56         ` Jon Steinhart
  2020-12-13  3:02         ` [TUHS] Were cron and at done at the same time? Or one before the other? Dan Cross
  1 sibling, 2 replies; 49+ messages in thread
From: Theodore Y. Ts'o @ 2020-12-13  1:07 UTC (permalink / raw)
  To: Dan Cross; +Cc: The Eunuchs Hysterical Society

On Wed, Dec 09, 2020 at 02:58:27PM -0500, Dan Cross wrote:
> To circle back to plan 9 for a moment, this was something that the open
> source folks who found their way to 9fans just couldn't grok. The answer to
> the question, "why don't you do all this work to support (emacs|a web
> browser|a C++ compiler|whatever du jour)?" was, "because there's little
> inherent research value in doing that, and this is a research system." That
> it was also a workaday system for a handful of folks was incidental; the
> goal wasn't world domination, it was advancing research and providing a
> comfortable environment for that work. Linus's response exemplifies this
> lack of understanding. (Disclaimer: I was very much an outsider looking in
> there, but it seems clear enough in retrospect.)

There was a similar dynamic with Minix, where Prof. Tanenbaum rejected
contributions to Minix because Minix wa a teaching system, and he
wanted to keep it simple.

The contrast is that with Linux, that contributions are accepted from
a large number of people, working at a large number of companies, that
all have different goals, and the challenge of maintainers is to
balance off the goals of many different contributors.  Contributions
don't get rejected just because "this is a {research,testing} OS".
The goal is to make the open source project as generally useful as
possible.

>     And notice how they aren't all that popular or well known? "Design" is
> >     like a religion - too much of it makes you inflexibly and unpopular.
> 
> That's a terrible metric.
> 
> I submit that neither of those systems were created with the explicit goal
> to become "popular", and the claim of inflexibility is unwarranted. Within
> their domain, that is as research systems, both are quite well known and
> remain highly influential.

From the open source perspective, it's an extremely important metric,
since if a system is generally useful, such that many different
entities find the system to be useful, that means that the project
will have more and more contributors.  Yes, those contributors may
have differing objectives, but this also gives you a larger
development community to make the project more useful.

The challenge is how to structure the project so that you can usefully
use a larger and larger number of contributors, and how to mediate
conflicts when objectives are in tension with each other.  (For
example, sometimes adding lots of fine-grained locking to improve CPU
scalability often comes at the cost of trashing UP and small SMP
performance.)

However, it's surprising how often that with the right amount of
encouragement, things like SMP vs UP performance is not an either/or,
but a both/and.  Granted, at the extremes, this isn't always going to
be true.  If you have to squeeze an OS into super-tiny
micro-controller, or if you want to optimize scalability for a
massiely large Sunfire E10k/E12k/E15k server, the only way to do this
is with a huge number of fine-grained locks in Solaris.  (And given
the profit margins on million dollar E10k versus a cheap Ultrasparc 5
workstation, it's not surprising that Solaris would optimize
performance for an E10k.)

> This is a common but annoying line of thought in the computer world:
> because something is useful and popular, it is good. My first car was a
> 1985 AMC Eagle; it was undeniably useful. It may have even been moderately
> popular at one point. But damn it was an awful car.
> 
> Linux is undeniably useful and it's arguably the most popular operating
> system in the world. And parts of it are really, really good. But simply
> put, that doesn't mean that its evolutionary path has landed in an
> inherently good place.

The question is what your objective function such that you consider
the endpoint evolutionary path is "a good place"?  My pre-existing
values are that a system is "good" if it can add value for many
different applications.

So I have a bit of an engineer's perspective of a system is good
because it is useful --- and part of being useful is that it is
secure, and reliable, and cost effective.  Having a clean architecture
is useful in so far as it makes reduces maintenance overhead and
improves reliability.  But forcing everything to use a file interface
merely for aethestics' sake is not terribly important for _my_
objective function.

And if popularity means that I can have engineers from Tencent, and
Huawei, and IBM, and SuSE, and Oracle, and Google all helping me make
a better file system for Linux, as opposed to having one company
shoulder all of the development costs --- then heck yes, I'll take
popularity any day.

Cheers,

					- Ted

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-13  1:07       ` Theodore Y. Ts'o
@ 2020-12-13  1:56         ` Jon Steinhart
  2020-12-13  2:58           ` Theodore Y. Ts'o
  2020-12-13  3:02         ` [TUHS] Were cron and at done at the same time? Or one before the other? Dan Cross
  1 sibling, 1 reply; 49+ messages in thread
From: Jon Steinhart @ 2020-12-13  1:56 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Theodore Y. Ts'o writes:
> > Linux is undeniably useful and it's arguably the most popular operating
> > system in the world. And parts of it are really, really good. But simply
> > put, that doesn't mean that its evolutionary path has landed in an
> > inherently good place.
>
> The question is what your objective function such that you consider
> the endpoint evolutionary path is "a good place"?  My pre-existing
> values are that a system is "good" if it can add value for many
> different applications.
>
> So I have a bit of an engineer's perspective of a system is good
> because it is useful --- and part of being useful is that it is
> secure, and reliable, and cost effective.  Having a clean architecture
> is useful in so far as it makes reduces maintenance overhead and
> improves reliability.  But forcing everything to use a file interface
> merely for aethestics' sake is not terribly important for _my_
> objective function.
>
> And if popularity means that I can have engineers from Tencent, and
> Huawei, and IBM, and SuSE, and Oracle, and Google all helping me make
> a better file system for Linux, as opposed to having one company
> shoulder all of the development costs --- then heck yes, I'll take
> popularity any day.

My two cents here is that the problem with the evolution of linux is that
many, many people are adding new stuff while the existing stuff is decaying.
Sure, the kernel is pretty stable, but user land is a mess where one has a
choice of many versions of everything, each of which is broken in a different
way.  My engineer's perspective is that the overcomplexity from lack of
architecture is resulting in reliability and maintenance issues.

And, if you can actually make a better file system, please go for it, you're
a better person than me.  I've looked that that code, and it's huge, has no
clearly defined entry and exit points, and is undocumented.  While I've been
too busy to deal with stuff, I found some minor bugs and a possible big
performance improvement just from trying to read the code.

I don't think that "it mostly works most of the time" is a great metric.

Jon

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-13  1:56         ` Jon Steinhart
@ 2020-12-13  2:58           ` Theodore Y. Ts'o
  2020-12-13  3:07             ` Jon Steinhart
  0 siblings, 1 reply; 49+ messages in thread
From: Theodore Y. Ts'o @ 2020-12-13  2:58 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society

On Sat, Dec 12, 2020 at 05:56:41PM -0800, Jon Steinhart wrote:
> 
> My two cents here is that the problem with the evolution of linux is that
> many, many people are adding new stuff while the existing stuff is decaying.
> Sure, the kernel is pretty stable, but user land is a mess where one has a
> choice of many versions of everything, each of which is broken in a different
> way.  My engineer's perspective is that the overcomplexity from lack of
> architecture is resulting in reliability and maintenance issues.

There are areas that are broken, but I suspect you're remember the
past with rose colored classes.  I remember plenty of bugs and
short-comings in BSD and commercial Unix systems in the late 80's and
early 90's.  They tended to show up for people who used those systems
in ways that were a bit off the beaten path compared to the more
common cases; but isn't that always the case?

> And, if you can actually make a better file system, please go for it, you're
> a better person than me.  I've looked that that code, and it's huge, has no
> clearly defined entry and exit points, and is undocumented.  While I've been
> too busy to deal with stuff, I found some minor bugs and a possible big
> performance improvement just from trying to read the code.

Did you report those bugs and potential performance improements?
Feedback is always gratefully accepted.

As far as documentation is concerned, it's not perfect, but it's
certainly not completely undocumented:

https://www.kernel.org/doc/html/latest/filesystems/index.html
https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html

Again, I suspect that you're remember the past with rose-colored
classes.  BSD FFS's fsck (or for that matter, fsck's from any of the
commercial Unix systems that I was able to see soures for) didn't have
regression test suites.  Ext2/3/4 was one of the first file system
fsck's that I'm aware with that was created with a regression test
suite from the very beginning.  And all of the major file systems in
Linux are developed using a very large library of functional and
stress tests:

https://thunk.org/gce-xfstests
https://thunk.org/android-xfstests
https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-xfstests.md


Was there anything like this during the "good old days"?  I sure don't
remember anything like this when I started with BSD 4.3 back in the
late 80's...

						- Ted

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-13  1:07       ` Theodore Y. Ts'o
  2020-12-13  1:56         ` Jon Steinhart
@ 2020-12-13  3:02         ` Dan Cross
  1 sibling, 0 replies; 49+ messages in thread
From: Dan Cross @ 2020-12-13  3:02 UTC (permalink / raw)
  To: Theodore Y. Ts'o; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 8927 bytes --]

On Sat, Dec 12, 2020 at 8:07 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:

> On Wed, Dec 09, 2020 at 02:58:27PM -0500, Dan Cross wrote:
> > To circle back to plan 9 for a moment, this was something that the open
> > source folks who found their way to 9fans just couldn't grok. The answer
> to
> > the question, "why don't you do all this work to support (emacs|a web
> > browser|a C++ compiler|whatever du jour)?" was, "because there's little
> > inherent research value in doing that, and this is a research system."
> That
> > it was also a workaday system for a handful of folks was incidental; the
> > goal wasn't world domination, it was advancing research and providing a
> > comfortable environment for that work. Linus's response exemplifies this
> > lack of understanding. (Disclaimer: I was very much an outsider looking
> in
> > there, but it seems clear enough in retrospect.)
>
> There was a similar dynamic with Minix, where Prof. Tanenbaum rejected
> contributions to Minix because Minix wa a teaching system, and he
> wanted to keep it simple.
>

Yes, but his aim there was pedagogy, not general use. In that I would argue
that he was successful.

The contrast is that with Linux, that contributions are accepted from
> a large number of people, working at a large number of companies, that
> all have different goals, and the challenge of maintainers is to
> balance off the goals of many different contributors.  Contributions
> don't get rejected just because "this is a {research,testing} OS".
> The goal is to make the open source project as generally useful as
> possible.


Sure, but that's Linux. Linux is not (Minix|Plan9|L4). QED, no?

Judging (Minix|Plan9|L4) by the same metrics by which one judges Linux is
not useful if those systems never aspired to those metrics.

>     And notice how they aren't all that popular or well known? "Design" is
> > >     like a religion - too much of it makes you inflexibly and
> unpopular.
> >
> > That's a terrible metric.
> >
> > I submit that neither of those systems were created with the explicit
> goal
> > to become "popular", and the claim of inflexibility is unwarranted.
> Within
> > their domain, that is as research systems, both are quite well known and
> > remain highly influential.
>
> From the open source perspective, it's an extremely important metric,
>

But the systems Linus mentioned weren't trying to be "successful" open
source systems by that definition. That's the point: the central thesis
here is that _that may be an important metric for Linux_, and by that
metric, Linux is very successful.

However Linus Torvalds is suggesting that other systems that explicitly
didn't judge themselves along those metrics are _unsuccessful_ in an
absolute sense because they didn't "succeed" by the metrics along which
Linux succeeded. This is analogous to suggesting that Yo-Yo Ma isn't
"successful" because he can't dunk a basketball like Michael Jordan, and
consequently isn't as famous. I'm willing to bet that more people know
Jordan's name than Ma's, and Ma himself would likely be among the first to
admit he's not NBA material, but that doesn't mean he isn't wildly
successful as a classically trained cellist. For that matter, Mick Jagger
is probably better known than Yo-Yo Ma, but I don't think the latter ever
aspired to be the frontman for the Rolling Stones, but I would never
suggest that he isn't an accomplished musician as a result.

Recall that the original context was a defense of Linux's purely organic
evolution vs some notion of "design up front" that Linus suggests both L4
and Plan9 sprang from. Nevermind that that is almost certainly not true of
either L4 or plan 9, but rather it's nonsensical to suggest that a more
design-oriented focus was the reason they weren't as successful as Linux
(as measured by popularity and deployment) as it completely ignores that
neither L4 nor plan9 were trying to do what Linux did in the first place.

since if a system is generally useful, such that many different
> entities find the system to be useful, that means that the project
> will have more and more contributors.  Yes, those contributors may
> have differing objectives, but this also gives you a larger
> development community to make the project more useful.
>

At one time, MS-DOS was wildly successful. There was a ton of software
written for it. That software was useful to a lot of people. But it would
be hard to argue that DOS was "better" on some technical plane than Unix.

I realize that some of this is moving the goalposts because no one defined
what "good" means in context. My definition includes things like
complexity, maintainability, and elegance. Some parts of Linux are nice
here; some ... not so much.

The challenge is how to structure the project so that you can usefully
> use a larger and larger number of contributors, and how to mediate
> conflicts when objectives are in tension with each other.  (For
> example, sometimes adding lots of fine-grained locking to improve CPU
> scalability often comes at the cost of trashing UP and small SMP
> performance.)
>
> However, it's surprising how often that with the right amount of
> encouragement, things like SMP vs UP performance is not an either/or,
> but a both/and.  Granted, at the extremes, this isn't always going to
> be true.  If you have to squeeze an OS into super-tiny
> micro-controller, or if you want to optimize scalability for a
> massiely large Sunfire E10k/E12k/E15k server, the only way to do this
> is with a huge number of fine-grained locks in Solaris.  (And given
> the profit margins on million dollar E10k versus a cheap Ultrasparc 5
> workstation, it's not surprising that Solaris would optimize
> performance for an E10k.)
>
> > This is a common but annoying line of thought in the computer world:
> > because something is useful and popular, it is good. My first car was a
> > 1985 AMC Eagle; it was undeniably useful. It may have even been
> moderately
> > popular at one point. But damn it was an awful car.
> >
> > Linux is undeniably useful and it's arguably the most popular operating
> > system in the world. And parts of it are really, really good. But simply
> > put, that doesn't mean that its evolutionary path has landed in an
> > inherently good place.
>
> The question is what your objective function such that you consider
> the endpoint evolutionary path is "a good place"?


Yes, I cheated here by not offering a definition.

My pre-existing
> values are that a system is "good" if it can add value for many
> different applications.
>

Well, my AMC Eagle got me around town, I drove to Bell Labs and back (from
central PA) in it when I was 16, and it had a hitch attachment that could
haul a camper. The engine was awesome and so was the heater, but every time
I drove over a speedbump a part fell off. If it was "good" by the metric of
adding value for different applications, then a car that did the same
things and where the rearview _didn't_ fall off every time I ran over a
pothole would have been better.

So I have a bit of an engineer's perspective of a system is good
> because it is useful --- and part of being useful is that it is
> secure, and reliable, and cost effective.  Having a clean architecture
> is useful in so far as it makes reduces maintenance overhead and
> improves reliability.  But forcing everything to use a file interface
> merely for aethestics' sake is not terribly important for _my_
> objective function.
>

One might argue that that misses the point of the interface: using the file
interface now allows pretty much all resources to be shared over the
network transparently, for example. Was it a purely aesthetic decision, or
was it a research angle that opened up new areas for exploration? Indeed,
some of the ideas that fell out of that as a consequence of "forcing"
everything to look like a file are now in Linux. Per-process namespaces and
/proc are obvious examples.

But taking it back to Linus's point...Whether one system uses that file
interface and another does not is immaterial, and I don't know that anyone
seriously argued that the popularity of the system wasn't predicated on
that. What you're describing here is a consequence of Linux's popularity;
Linux wasn't more popular than plan9 necessarily because it had mmap and
sockets and TTYs, but rather because it cloned an existing design that was
already very popular and packaged that up free of the legal and financial
entanglements of Unix, and also because plan9 just _wasn't trying to be
popular in the same way_.

And if popularity means that I can have engineers from Tencent, and
> Huawei, and IBM, and SuSE, and Oracle, and Google all helping me make
> a better file system for Linux, as opposed to having one company
> shoulder all of the development costs --- then heck yes, I'll take
> popularity any day.
>

That's fair, but that wasn't the original context.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 11302 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-13  2:58           ` Theodore Y. Ts'o
@ 2020-12-13  3:07             ` Jon Steinhart
  2020-12-13 16:49               ` Theodore Y. Ts'o
  0 siblings, 1 reply; 49+ messages in thread
From: Jon Steinhart @ 2020-12-13  3:07 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Theodore Y. Ts'o writes:
> > And, if you can actually make a better file system, please go for it, you're
> > a better person than me.  I've looked that that code, and it's huge, has no
> > clearly defined entry and exit points, and is undocumented.  While I've been
> > too busy to deal with stuff, I found some minor bugs and a possible big
> > performance improvement just from trying to read the code.
>
> Did you report those bugs and potential performance improements?
> Feedback is always gratefully accepted.
>
> As far as documentation is concerned, it's not perfect, but it's
> certainly not completely undocumented:
>
> https://www.kernel.org/doc/html/latest/filesystems/index.html
> https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html
>
> Again, I suspect that you're remember the past with rose-colored
> classes.  BSD FFS's fsck (or for that matter, fsck's from any of the
> commercial Unix systems that I was able to see soures for) didn't have
> regression test suites.  Ext2/3/4 was one of the first file system
> fsck's that I'm aware with that was created with a regression test
> suite from the very beginning.  And all of the major file systems in
> Linux are developed using a very large library of functional and
> stress tests:

No, not yet, because I haven't had the time to test.

And sorry, I wasn't clear.  I wasn't talking about the code for a
particular filesystem, I was talking about the generic filesystem
code.

Jon

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-13  3:07             ` Jon Steinhart
@ 2020-12-13 16:49               ` Theodore Y. Ts'o
  2020-12-13 19:06                 ` [TUHS] Were cron and at done at the same time? Or one before the other? [ really linux and filesystems ] Jon Steinhart
  0 siblings, 1 reply; 49+ messages in thread
From: Theodore Y. Ts'o @ 2020-12-13 16:49 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society

On Sat, Dec 12, 2020 at 07:07:15PM -0800, Jon Steinhart wrote:
> Theodore Y. Ts'o writes:
> > > And, if you can actually make a better file system, please go for it, you're
> > > a better person than me.  I've looked that that code, and it's huge, has no
> > > clearly defined entry and exit points, and is undocumented.  While I've been
> > > too busy to deal with stuff, I found some minor bugs and a possible big
> > > performance improvement just from trying to read the code.
> >
> > Did you report those bugs and potential performance improements?
> > Feedback is always gratefully accepted.
> >
> > As far as documentation is concerned, it's not perfect, but it's
> > certainly not completely undocumented:
> >
> > https://www.kernel.org/doc/html/latest/filesystems/index.html
> > ...
> 
> And sorry, I wasn't clear.  I wasn't talking about the code for a
> particular filesystem, I was talking about the generic filesystem
> code.

It's certainly not perfect; if you'd like to suggest improvements,
again, they would be gratefully accepted, the first link I sent you
was documentation for the generic file system code, and while there is
certainly more that I'd love to see documented (improvements and bug
reports gratefully accepted), the entry points are certainly one of
the things that is quite well defined:

https://www.kernel.org/doc/html/latest/filesystems/vfs.html

Cheers,

					- Ted

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other? [ really linux and filesystems ]
  2020-12-13 16:49               ` Theodore Y. Ts'o
@ 2020-12-13 19:06                 ` Jon Steinhart
  0 siblings, 0 replies; 49+ messages in thread
From: Jon Steinhart @ 2020-12-13 19:06 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Theodore Y. Ts'o writes:
> On Sat, Dec 12, 2020 at 07:07:15PM -0800, Jon Steinhart wrote:
> > Theodore Y. Ts'o writes:
> > > > And, if you can actually make a better file system, please go for it, you're
> > > > a better person than me.  I've looked that that code, and it's huge, has no
> > > > clearly defined entry and exit points, and is undocumented.  While I've been
> > > > too busy to deal with stuff, I found some minor bugs and a possible big
> > > > performance improvement just from trying to read the code.
> > >
> > > Did you report those bugs and potential performance improements?
> > > Feedback is always gratefully accepted.
> > >
> > > As far as documentation is concerned, it's not perfect, but it's
> > > certainly not completely undocumented:
> > >
> > > https://www.kernel.org/doc/html/latest/filesystems/index.html
> > > ...
> > 
> > And sorry, I wasn't clear.  I wasn't talking about the code for a
> > particular filesystem, I was talking about the generic filesystem
> > code.
>
> It's certainly not perfect; if you'd like to suggest improvements,
> again, they would be gratefully accepted, the first link I sent you
> was documentation for the generic file system code, and while there is
> certainly more that I'd love to see documented (improvements and bug
> reports gratefully accepted), the entry points are certainly one of
> the things that is quite well defined:
>
> https://www.kernel.org/doc/html/latest/filesystems/vfs.html
>
> Cheers,
>
> 					- Ted

This isn't really on-topic for TUHS so I'll give you a longer answer by
private email.  Yes, I agree that there is documentation for parts of the
code, some of which even refers to the current version.  Been through a
good pile of it.  Still no clue as to the entry points in namei.c.

Jon

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-09 16:01   ` Bakul Shah
  2020-12-09 16:11     ` Clem Cole
@ 2020-12-14 20:28     ` Dave Horsfall
  2020-12-14 22:23       ` Thomas Paulsen
                         ` (2 more replies)
  1 sibling, 3 replies; 49+ messages in thread
From: Dave Horsfall @ 2020-12-14 20:28 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 425 bytes --]

On Wed, 9 Dec 2020, Bakul Shah wrote:

> please don’t blame c++ on pascal folks. stroustrup had nothing to do 
> with pascal.  

I certainly hope not; Pascal was meant to be a teaching language, not a 
production language.  As for C++, well, what can I say?  It should've been 
called C-- ...

You wrote your algorithm in Pascal, debugged it, and then rewrote it in 
your favourite language (in my case, ALGOL-W).

-- Dave

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-14 20:28     ` Dave Horsfall
@ 2020-12-14 22:23       ` Thomas Paulsen
  2020-12-14 23:04         ` Andrew Hume
  2020-12-14 23:59       ` Harald Arnesen
  2020-12-15  2:57       ` Bakul Shah
  2 siblings, 1 reply; 49+ messages in thread
From: Thomas Paulsen @ 2020-12-14 22:23 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: tuhs

for pascal Niklaus Emil Wirth is the key and not Ken&Dennis.

--- Ursprüngliche Nachricht ---
Von: Dave Horsfall <dave@horsfall.org>
Datum: 14.12.2020 21:28:01
An: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Betreff: Re: [TUHS] Were cron and at done at the same time? Or one before  the other?

On Wed, 9 Dec 2020, Bakul Shah wrote:

> please don’t blame c++ on pascal folks. stroustrup had nothing to do

> with pascal.  

I certainly hope not; Pascal was meant to be a teaching language, not a

production language.  As for C++, well, what can I say?  It should've been

called C-- ...

You wrote your algorithm in Pascal, debugged it, and then rewrote it in

your favourite language (in my case, ALGOL-W).

-- Dave



^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-14 22:23       ` Thomas Paulsen
@ 2020-12-14 23:04         ` Andrew Hume
  0 siblings, 0 replies; 49+ messages in thread
From: Andrew Hume @ 2020-12-14 23:04 UTC (permalink / raw)
  To: Thomas Paulsen; +Cc: UNIX Heritage Society

i remember going to a wirth talk in sydney with john lions.
the discussion of the day was john trying to persuade niklaus about the
value of multiprogramming. “why would you want to do anything else while your
computer was printing?” it was a long discussion.

> On Dec 14, 2020, at 2:23 PM, Thomas Paulsen <thomas.paulsen@firemail.de> wrote:
> 
> for pascal Niklaus Emil Wirth is the key and not Ken&Dennis.
> 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-14 20:28     ` Dave Horsfall
  2020-12-14 22:23       ` Thomas Paulsen
@ 2020-12-14 23:59       ` Harald Arnesen
  2020-12-17  4:08         ` John Cowan
  2020-12-15  2:57       ` Bakul Shah
  2 siblings, 1 reply; 49+ messages in thread
From: Harald Arnesen @ 2020-12-14 23:59 UTC (permalink / raw)
  To: tuhs

Dave Horsfall [14.12.2020 21:28]:

> You wrote your algorithm in Pascal, debugged it, and then rewrote it in 
> your favourite language (in my case, ALGOL-W).

Now THATS's a sane language. I have never used it professionally (or
much at all), but I can see it's what Algol-687 should have been. Even
better than Simula, which I have used a bit in the past.
-- 
Hilsen Harald

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-14 20:28     ` Dave Horsfall
  2020-12-14 22:23       ` Thomas Paulsen
  2020-12-14 23:59       ` Harald Arnesen
@ 2020-12-15  2:57       ` Bakul Shah
  2020-12-15  3:05         ` Warner Losh
  2 siblings, 1 reply; 49+ messages in thread
From: Bakul Shah @ 2020-12-15  2:57 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Dec 14, 2020, at 12:28 PM, Dave Horsfall <dave@horsfall.org> wrote:
> 
> On Wed, 9 Dec 2020, Bakul Shah wrote:
> 
>> please don’t blame c++ on pascal folks. stroustrup had nothing to do with pascal.  
> 
> I certainly hope not; Pascal was meant to be a teaching language, not a production language.  As for C++, well, what can I say?  It should've been called C-- ...

I liked C with classes though never had a chance to use it.
You do know there was a C-- (designed by Simon Peyton Jones &
Norman Ramsay) as a "portable assembly language" (even more
so than C) as a target for HLL compilers. 

> You wrote your algorithm in Pascal, debugged it, and then rewrote it in your favourite language (in my case, ALGOL-W).

Now why didn't Don Knuth think of that for TeX?

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-15  2:57       ` Bakul Shah
@ 2020-12-15  3:05         ` Warner Losh
  0 siblings, 0 replies; 49+ messages in thread
From: Warner Losh @ 2020-12-15  3:05 UTC (permalink / raw)
  To: Bakul Shah; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

On Mon, Dec 14, 2020 at 7:58 PM Bakul Shah <bakul@iitbombay.org> wrote:

> On Dec 14, 2020, at 12:28 PM, Dave Horsfall <dave@horsfall.org> wrote:
> > You wrote your algorithm in Pascal, debugged it, and then rewrote it in
> your favourite language (in my case, ALGOL-W).
>
> Now why didn't Don Knuth think of that for TeX?


It's by far not the only program that's translated from a pascal-oid into C
before being compiled. The Moria game from back in the late 80s was
originally written in Pascal and ported to the PC by using a Pascal to C
compiler someone had written because it was easier than getting it to
compile under Turbo Pascal or something. Though that may have been a
one-shot deal. The code has since been rewritten two or three times...

Warner

[-- Attachment #2: Type: text/html, Size: 1196 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-14 23:59       ` Harald Arnesen
@ 2020-12-17  4:08         ` John Cowan
  0 siblings, 0 replies; 49+ messages in thread
From: John Cowan @ 2020-12-17  4:08 UTC (permalink / raw)
  To: Harald Arnesen; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]

On Mon, Dec 14, 2020 at 7:00 PM Harald Arnesen <skogtun@gmail.com> wrote:


> Now THATS's a sane language. I have never used it professionally (or
> much at all), but I can see it's what Algol-687 should have been.
>

I studied A68 in detail with a friend of mine in 1976, and I've always
admired it greatly.  The van Wijngaarden two-level used in the original
report was rather opaque, though the revised report was much more readable
(and did not only the syntax and the static semantics, but the dynamic
semantics as well).  Only when I got a hold of an actual A68 textbook years
later did I actually see a straight grammar of the language, which got me
interested in the language again.

Sometimes I wonder what would have happened if A68 had become the
medium-level language of Unix, and Pascal had become the language of
non-Unix, instead of both of them using C.  (The four segment registers of
the x86 mirror exactly the way Pascal pointers work: it is statically known
whether a pointer points to the stack, the code, the data, or the heap
segment.)



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
And it was said that ever after, if any man looked in that Stone,
unless he had a great strength of will to turn it to other purpose,
he saw only two aged hands withering in flame.   --"The Pyre of Denethor"

[-- Attachment #2: Type: text/html, Size: 3069 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-13  2:02 Noel Chiappa
@ 2020-12-13  2:08 ` Clem Cole
  0 siblings, 0 replies; 49+ messages in thread
From: Clem Cole @ 2020-12-13  2:08 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

Amen

On Sat, Dec 12, 2020 at 9:02 PM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

>     > From: "Theodore Y. Ts'o"
>
>     > Having a clean architecture is useful in so far as it makes reduces
>     > maintenance overhead and improves reliability.
>
> I would put it differently, hence my aphorism that: "the sign of great
> architecture is not how well it does the things it was designed to do, but
> how
> well it does things you never imagined it would be used for".
>
> I suppose you could say that reducing maintenance and improving reliability
> are examples of the natural consequences of that, but to me those are
> limited
> special cases of the more general statement. My sense is that systems
> decline
> over time because of what I call 'system cancer': as they are modified to
> do
> more and more (new) things, the changes are not usually very cleanly
> integrated, and eventually one winds up with a big pile. (Examples of this
> abound; I'm sure we can all think of several.)
>
>         Noel
>
>

[-- Attachment #2: Type: text/html, Size: 1486 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
@ 2020-12-13  2:02 Noel Chiappa
  2020-12-13  2:08 ` Clem Cole
  0 siblings, 1 reply; 49+ messages in thread
From: Noel Chiappa @ 2020-12-13  2:02 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: "Theodore Y. Ts'o"

    > Having a clean architecture is useful in so far as it makes reduces
    > maintenance overhead and improves reliability.

I would put it differently, hence my aphorism that: "the sign of great
architecture is not how well it does the things it was designed to do, but how
well it does things you never imagined it would be used for".

I suppose you could say that reducing maintenance and improving reliability
are examples of the natural consequences of that, but to me those are limited
special cases of the more general statement. My sense is that systems decline
over time because of what I call 'system cancer': as they are modified to do
more and more (new) things, the changes are not usually very cleanly
integrated, and eventually one winds up with a big pile. (Examples of this
abound; I'm sure we can all think of several.)

	Noel


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
@ 2020-12-09 19:25 Noel Chiappa
  0 siblings, 0 replies; 49+ messages in thread
From: Noel Chiappa @ 2020-12-09 19:25 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Niklas Karlsson

    > Just consider Multics, or IBM's "Future System".

Here's a nice irony for you: one of the key people in killing off FS was
reported to me (by someone who should have known) to be Jerry Saltzer (of
Multics fame). That wasn't the only time he did something like thst, either;
when MIT leaned on him to take over Athena, the first thing he did was to take
a lot of their ambitious system plans, and ditch them; they fell back to
mostly 'off the shelf' stuff: pretty much vanilla 4.2, etc.


Multics itself has an interesting story, quite different from the popular
image among those who know little (or nothing) of it. The system, as it was
when Honeywell pulled the plug on further generations of new hardware (in the
mid-80's) was very different from the system as originally envisaged by MIT
(in the mid-60's); it had undergone a massive amount 'experience-based
evolution' during those 20 years.

For instance, the original concept was to have a process per command (like
Unix), but that was dropped early on (because Multics processes were too
'expensive'); they wound up going with doing commands with inter-segment
procedure calls. (Which has the nice benefit that when a command faults, you
can get dropped right into the debugger, with the failed instance there to
look at.) If you read the Organick book on Multics, it describes a much
different system: e.g. in Organick there's a 'linkage segment' (used for
inter-segment pointers, in pure-code segments) per code segment, but in
reality Multics, as distributed, used a single 'combined linkage segment'
(which also contained the stack, also unlike the original design, where the
stack was a separate segment).

There were also numerous places where major sub-systems were re-implemeneted
from scratch, with major changes (often great simplifications): one major
re-do was the New Storage System, but that one had major new features (based
on operationally-shown needs, like the 4.1/.2 Fast File System), so it's not a
'simplification' case. There's one I read about which was much simpler the second
time it was implemented, I think it was IPC?

	Noel

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-08 19:20     ` Michael Kjörling
@ 2020-12-09  2:00       ` Dave Horsfall
  0 siblings, 0 replies; 49+ messages in thread
From: Dave Horsfall @ 2020-12-09  2:00 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

On Tue, 8 Dec 2020, Michael Kjörling wrote:

> If you have at but not cron, then implementing the other doesn't seem 
> quite as straightforward. It would certainly still be possible, but it 
> would definitely give rise to the question of "wouldn't it be real nice 
> if I could set this task up to run on a recurring basis?" followed by 
> "wouldn't it make more sense for the run-stuff-at-some-time task to run 
> from the recurring-execution tool, than the other way around?".

I've never seen a *nix (since the 70s) that didn't have CRON (in one form 
or another)...  And on my FreeBSD system, "atrun" is called every 5 
minutes, so /etc/crontab will need to be edited for finer granularity.

-- Dave

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-08 18:51 ` Mary Ann Horton
  2020-12-08 19:05   ` Larry McVoy
@ 2020-12-08 19:39   ` Clem Cole
  1 sibling, 0 replies; 49+ messages in thread
From: Clem Cole @ 2020-12-08 19:39 UTC (permalink / raw)
  To: Mary Ann Horton; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

Correct.  at was a v7-ism.   Trying to put a nicer face on the idea - that
is to say, I looked at the "at" command as a user-mode (command) front-end
to cron so you didn't have to edit the crontab yourself.  The later had
been around as a system support idea, since at least 6th edition - maybe
5th.

On Tue, Dec 8, 2020 at 1:51 PM Mary Ann Horton <mah@mhorton.net> wrote:

> My V6 manual has cron(VIII) - documentation of /usr/lib/crontab - but no
> mention of at.
>
> This is consistent with my recollection - I first saw at in V7.
>
>      Mary Ann
>
> On 12/8/20 10:11 AM, ron minnich wrote:
> > When I got into Unix in 1976 cron and at were both there.
> >
> > I got to wondering for no particular reason which came first -- I had
> > always assumed cron, but ...?
> >
> > Anyone know?
>

[-- Attachment #2: Type: text/html, Size: 1233 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-08 19:05   ` Larry McVoy
@ 2020-12-08 19:20     ` Michael Kjörling
  2020-12-09  2:00       ` Dave Horsfall
  0 siblings, 1 reply; 49+ messages in thread
From: Michael Kjörling @ 2020-12-08 19:20 UTC (permalink / raw)
  To: tuhs

On 8 Dec 2020 11:05 -0800, from lm@mcvoy.com (Larry McVoy):
> Doesn't it stand to reason that cron would come first, isn't at implemented
> with an entry in a crontab?

I don't know if it is implemented that way, but if you have cron, then
I suspect you could implement some form of at with even a pretty simple
shell script that runs once a minute (via cron) to parse a set of files
to see what should be run now as opposed to later.

If you have at but not cron, then implementing the other doesn't seem
quite as straightforward. It would certainly still be possible, but it
would definitely give rise to the question of "wouldn't it be real nice
if I could set this task up to run on a recurring basis?" followed by
"wouldn't it make more sense for the run-stuff-at-some-time task to run
from the recurring-execution tool, than the other way around?".

Certainly the step from cron to at seems fairly obvious; not all tasks
that are to be executed at some point in time lend themselves well to a
recurring nature. Sometimes you really want to do something just once,
just not right now.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-08 18:51 ` Mary Ann Horton
@ 2020-12-08 19:05   ` Larry McVoy
  2020-12-08 19:20     ` Michael Kjörling
  2020-12-08 19:39   ` Clem Cole
  1 sibling, 1 reply; 49+ messages in thread
From: Larry McVoy @ 2020-12-08 19:05 UTC (permalink / raw)
  To: Mary Ann Horton; +Cc: tuhs

Doesn't it stand to reason that cron would come first, isn't at implemented
with an entry in a crontab?

On Tue, Dec 08, 2020 at 10:51:05AM -0800, Mary Ann Horton wrote:
> My V6 manual has cron(VIII) - documentation of /usr/lib/crontab - but no
> mention of at.
> 
> This is consistent with my recollection - I first saw at in V7.
> 
> ?????? Mary Ann
> 
> On 12/8/20 10:11 AM, ron minnich wrote:
> >When I got into Unix in 1976 cron and at were both there.
> >
> >I got to wondering for no particular reason which came first -- I had
> >always assumed cron, but ...?
> >
> >Anyone know?

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

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [TUHS] Were cron and at done at the same time? Or one before the other?
  2020-12-08 18:11 ron minnich
@ 2020-12-08 18:51 ` Mary Ann Horton
  2020-12-08 19:05   ` Larry McVoy
  2020-12-08 19:39   ` Clem Cole
  0 siblings, 2 replies; 49+ messages in thread
From: Mary Ann Horton @ 2020-12-08 18:51 UTC (permalink / raw)
  To: tuhs

My V6 manual has cron(VIII) - documentation of /usr/lib/crontab - but no 
mention of at.

This is consistent with my recollection - I first saw at in V7.

     Mary Ann

On 12/8/20 10:11 AM, ron minnich wrote:
> When I got into Unix in 1976 cron and at were both there.
>
> I got to wondering for no particular reason which came first -- I had
> always assumed cron, but ...?
>
> Anyone know?

^ permalink raw reply	[flat|nested] 49+ messages in thread

* [TUHS] Were cron and at done at the same time? Or one before the other?
@ 2020-12-08 18:11 ron minnich
  2020-12-08 18:51 ` Mary Ann Horton
  0 siblings, 1 reply; 49+ messages in thread
From: ron minnich @ 2020-12-08 18:11 UTC (permalink / raw)
  To: TUHS main list

When I got into Unix in 1976 cron and at were both there.

I got to wondering for no particular reason which came first -- I had
always assumed cron, but ...?

Anyone know?

^ permalink raw reply	[flat|nested] 49+ messages in thread

end of thread, other threads:[~2020-12-17  4:09 UTC | newest]

Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-09  4:35 [TUHS] Were cron and at done at the same time? Or one before the other? M Douglas McIlroy
2020-12-09 15:40 ` Clem Cole
2020-12-09 15:46   ` Niklas Karlsson
2020-12-09 16:01   ` Bakul Shah
2020-12-09 16:11     ` Clem Cole
2020-12-09 17:05       ` Bakul Shah
2020-12-09 17:42         ` Dan Stromberg
2020-12-09 23:46           ` Nemo Nusquam
2020-12-14 20:28     ` Dave Horsfall
2020-12-14 22:23       ` Thomas Paulsen
2020-12-14 23:04         ` Andrew Hume
2020-12-14 23:59       ` Harald Arnesen
2020-12-17  4:08         ` John Cowan
2020-12-15  2:57       ` Bakul Shah
2020-12-15  3:05         ` Warner Losh
     [not found]   ` <CAC20D2PXZY9aWgDf-RknROs6JbKEUjzbQ2BRzfTgTR07pXni3g@mail.g mail.com>
2020-12-09 16:04     ` John Foust
2020-12-09 16:40   ` Warner Losh
2020-12-09 16:53     ` Jon Steinhart
2020-12-09 16:58   ` Theodore Y. Ts'o
2020-12-09 19:58     ` Dan Cross
2020-12-09 20:30       ` Will Senn
2020-12-13  1:07       ` Theodore Y. Ts'o
2020-12-13  1:56         ` Jon Steinhart
2020-12-13  2:58           ` Theodore Y. Ts'o
2020-12-13  3:07             ` Jon Steinhart
2020-12-13 16:49               ` Theodore Y. Ts'o
2020-12-13 19:06                 ` [TUHS] Were cron and at done at the same time? Or one before the other? [ really linux and filesystems ] Jon Steinhart
2020-12-13  3:02         ` [TUHS] Were cron and at done at the same time? Or one before the other? Dan Cross
2020-12-09 23:22     ` Bakul Shah
2020-12-09 23:44       ` Steffen Nurpmeso
2020-12-09 23:51         ` Steffen Nurpmeso
2020-12-10  0:19   ` [TUHS] Cole's Slaw John Gilmore
2020-12-10  0:29     ` Larry McVoy
2020-12-10  0:53       ` Erik E. Fair
2020-12-10  3:10         ` George Michaelson
2020-12-12 21:11       ` Dave Horsfall
2020-12-10  1:49     ` John Cowan
2020-12-10  2:12       ` Jon Steinhart
2020-12-12  2:56   ` [TUHS] Were cron and at done at the same time? Or one before the other? Dave Horsfall
2020-12-12 19:10     ` scj
  -- strict thread matches above, loose matches on Subject: below --
2020-12-13  2:02 Noel Chiappa
2020-12-13  2:08 ` Clem Cole
2020-12-09 19:25 Noel Chiappa
2020-12-08 18:11 ron minnich
2020-12-08 18:51 ` Mary Ann Horton
2020-12-08 19:05   ` Larry McVoy
2020-12-08 19:20     ` Michael Kjörling
2020-12-09  2:00       ` Dave Horsfall
2020-12-08 19:39   ` Clem Cole

The Unix Heritage Society mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/tuhs

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 tuhs tuhs/ http://inbox.vuxu.org/tuhs \
		tuhs@minnie.tuhs.org
	public-inbox-index tuhs

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git