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-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
* [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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).