Den ons 9 dec. 2020 kl 16:42 skrev Clem Cole <clemc(a)ccc.com>om>: 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

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(a)iitbombay.org> wrote:

On Wed, Dec 9, 2020 at 9:08 AM Bakul Shah <bakul(a)iitbombay.org> wrote: 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!"

On Wed, 9 Dec 2020, Bakul Shah wrote: 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 Mon, Dec 14, 2020 at 7:00 PM Harald Arnesen <skogtun(a)gmail.com> wrote: 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(a)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"

On Mon, Dec 14, 2020 at 7:58 PM Bakul Shah <bakul(a)iitbombay.org> wrote: 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

Warner Losh writes: No, it's a song by Zero.

On Wed, Dec 9, 2020 at 12:07 PM Theodore Y. Ts'o <tytso(a)mit.edu> wrote: 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 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. 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 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.

On Wed, Dec 09, 2020 at 02:58:27PM -0500, Dan Cross wrote: 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. 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.) 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

On Sat, Dec 12, 2020 at 05:56:41PM -0800, Jon Steinhart wrote: 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? 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-xfstest… 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

On Sat, Dec 12, 2020 at 07:07:15PM -0800, Jon Steinhart wrote: 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

On Sat, Dec 12, 2020 at 8:07 PM Theodore Y. Ts'o <tytso(a)mit.edu> wrote: 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 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. 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 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 Yes, I cheated here by not offering a definition. My pre-existing 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 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 That's fair, but that wasn't the original context. - Dan C.

Bakul Shah wrote in <E204EAE4-3D80-4774-BC62-CD6678EF884B(a)iitbombay.org>rg>: |On Dec 9, 2020, at 9:06 AM, Theodore Y. Ts'o <tytso(a)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)

Clem Cole <clemc(a)ccc.com> wrote: 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

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

On Wed, 9 Dec 2020, Larry McVoy wrote: 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

John Cowan writes: 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

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: