* [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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ messages in thread
end of thread, other threads:[~2020-12-17 4:09 UTC | newest] Thread overview: 40+ 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
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).