* [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; 41+ 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] 41+ messages in thread
* Re: [TUHS] Were cron and at done at the same time? Or one before the other? 2020-12-08 18:11 [TUHS] Were cron and at done at the same time? Or one before the other? 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; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ messages in thread
* [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; 41+ 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] 41+ messages in thread
* Re: [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 2020-12-09 15:46 ` Niklas Karlsson ` (5 more replies) 0 siblings, 6 replies; 41+ 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] 41+ 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 ` (4 subsequent siblings) 5 siblings, 0 replies; 41+ 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] 41+ 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> ` (3 subsequent siblings) 5 siblings, 2 replies; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ messages in thread
[parent not found: <CAC20D2PXZY9aWgDf-RknROs6JbKEUjzbQ2BRzfTgTR07pXni3g@mail.g mail.com>]
* 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; 41+ 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] 41+ 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 2020-12-12 2:56 ` Dave Horsfall 5 siblings, 1 reply; 41+ 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] 41+ 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; 41+ 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] 41+ 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-12 2:56 ` Dave Horsfall 5 siblings, 2 replies; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ 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 ` Dan Cross 1 sibling, 2 replies; 41+ 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] 41+ 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 ` Dan Cross 1 sibling, 1 reply; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ 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 0 siblings, 0 replies; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ 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 ` (4 preceding siblings ...) 2020-12-09 16:58 ` Theodore Y. Ts'o @ 2020-12-12 2:56 ` Dave Horsfall 2020-12-12 19:10 ` scj 5 siblings, 1 reply; 41+ 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] 41+ messages in thread
* Re: [TUHS] Were cron and at done at the same time? Or one before the other? 2020-12-12 2:56 ` Dave Horsfall @ 2020-12-12 19:10 ` scj 0 siblings, 0 replies; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ 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; 41+ 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] 41+ messages in thread
end of thread, other threads:[~2020-12-17 4:09 UTC | newest] Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-12-08 18:11 [TUHS] Were cron and at done at the same time? Or one before the other? 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 2020-12-09 4:35 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 3:02 ` 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-12 2:56 ` Dave Horsfall 2020-12-12 19:10 ` scj 2020-12-09 19:25 Noel Chiappa 2020-12-13 2:02 Noel Chiappa 2020-12-13 2:08 ` 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).