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
[-- 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 --]
[-- 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 --]
[-- 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 --]
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
[-- 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 --]
[-- 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 --]
Warner Losh writes:
>
> I agree, but I thought Cole's Law was thinly sliced cabbage.
>
> Warner
No, it's a song by Zero.
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
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
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.
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)
[-- 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 --]
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)
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
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.
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
[-- 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 --]
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
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
[-- 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
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
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
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
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
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
[-- 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 --]
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
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
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
[-- 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
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
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.
>
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
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?
[-- 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 --]
[-- 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 --]