On Mon, Feb 08, 2021 at 10:58:08PM -0500, M Douglas McIlroy wrote: Well, let's take a look at those system calls. They fall into a number of major categories: *) BSD innovations *) BSD socket interfaces (so if you want TCP/IP... is it bloat?) *) BSD job control *) BSD effective id and its extensions *) BSD groups *) New versions to maintain stable ABI's, e.g., (dup vs dup2 vs dup3, wait vs wait3 vs wait4 vs waitpid, stat vs stat64, lstat vs lstat64, chown vs chown32, etc.) *) System V IPC support (is support for enterprise databases like Oracle "bloat"?) *) Posix real-time extensions *) Posix extended attributes *) Windows file streams support (the original reason for the *at(2) system calls -- openat, linkat, renameat, and a dozen more) Ok, that last I'd agree was *pure* bloat, and an amazingly bad idea. But there are plenty of people who have bugged/begged me to add windows file streams because they were *convinced* it was a critical feature. And I dare say bug-for-bugs Windows compatibility was worth millions of $$$ of potential sales, which is why they agreed to add it --- and why I kept on getting nagged to add that feature to ext4 (and I pushed back where the Solaris developers caved, so there. :-) As for things like System V IPC support, that was only added to Linux because it was worth $$$, because enterprise databases like DB2 and Oracle demanded it. Is that evidence of "cancer"? You might not want it, but that's a great example of "one person's bloat is another person's critical feature". Or consider the dozen plus BSD sockets interface, which if removed would mean no TCP/IP support, and no graphical windowing systems. Critical feature, or bloat? But hey, if you only want V7 Unix, why are you complaining? Just go and use it, and give up on all of this cancerous new features. And I promise to get off of your lawn. :-)

fcntl locking semantics, where a close of *any* file descriptor, even a fd cloned via dup(2) or fork(2) will release the lock.

From BTSJ 57:6:

The file system maintains no locks visible to the user, nor is there any restriction on the number of users who may have a file open for reading or writing. Although it is possible for the contents of a file to become scrambled when two users write on it simultaneously, in practice difficulties do not arise. We take the view that locks are neither necessary nor sufficient, in our environment, to prevent interference between users of the same file. They are unnecessary because we are not faced with large, single-file databases maintained by independent processes. They are insufficient because locks in the ordinary sense, whereby one user is prevented from writing on a file that another user is reading, cannot prevent confusion when, for example, both users are editing a file with an editor that makes a copy of the file being edited. There are, however, sufficient internal interlocks to maintain the logical consistency of the file system when two users engage simultaneously in activities such as writing on the same file, creating files in the same directory, or deleting each other’s open files.

Everything can be implemented in terms of a turing machine tape, so I'm sure that's true. Whether or not it would be *performant* and *secure* in the face of application level bugs might be a different story, though.

In fact, some of the terrible semantics of the Posix interfaces exist only because there were traditional Unix vendors on the standards committee insisting on semantics that *could* be implemented using a user-mode library on top of normal file API's (I'm looking at you, fcntl locking semantics, where a close of *any* file descriptor, even a fd cloned via dup(2) or fork(2) will release the lock). So yes, Posix fcntl(2) locking *can* be implemented in terms of normal file API's.... AND IT WAS A TERRIBLE IDEA. (For more details, see [1].)

I could go on about other spectactularly bad ideas enshrined in POSIX, such as telldir(2) and seekdir(2), which date all the way back to the assumption that directories should only be implemented in terms of linear linked lists with O(n) lookup performance, but I don't whine about that as feature bloat imposed by external standards, but just the cost of doing business. (Or at least, of relevance.)

I'm not sure what you're referring to; if you mean the *at(2) system calls, which is why they exist in Linux (not for !@#!? Windows file streams support); they are needed to provide secure and performant user-mode file servers for things like Samba. Trying to implement a user-space file server using only the V7 Unix primitives will cause you to have some really horrible Time of Use vs Time of Check (TOUTOC) security gaps; you can narrow the TOUTOC races with some terrible performance sucking impacts, but removing them entirely is almost impossible.

That's because most people aren't going to port or rewrite application software for some random OS, whether it is a research OS or someone's new "simple, clean, reimplementation". And most users do expect to have a working web browser.... and text editor..., and their favorite games, whether it's nethack or spacewars, etc., etc., etc.

While I use linux, it's no longer a system that I trust in any way. It's huge, bloated, rats-nest undocumented code. Yes, I know that a small percentage of people like Ted spend a lot of time on the code and therefore know it well. But I find it an impenetrable mess. When I first had a need to look at the UNIX kernel, it was easy to figure out what was going on. Not so with linux. Of course, I'm getting old and maybe not as good at this stuff as I used to be.

I won't dispute your age, or how many layers of pearl are on the seed Larry, but MP unix was a thing long long ago. I am pretty sure it was written up in BSTJ, and there was Pyramid by 1984/5 and an MP unix system otherwise running at Melbourne University (Rob Elz) around 1988. You might be ancient, but you weren't THAT ancient in the 1980s. anyway, pearls before swine, and age before beauty. -G

On Tue, Feb 9, 2021 at 9:25 PM Larry McVoy <lm(a)mcvoy.com> wrote: All in all, that was a pretty tame Rant, Larry. :-) Who among us is running v7, or some other kernel that we all love I had a stint in life where my "primary" environment was a VT320 hooked up to a VAXstation running VMS, from which I'd telnet to a Unix machine. Subjectively, it was among the more productive times in my life professionally: I felt that I wrote good code and could concentrate on what I was working on. Fast forward 15 years (so a little 10 years ago), I'm sitting in front of a Mac Pro desktop with two large displays and an infinite number of browser tabs open and I feel almost hopelessly productive. I just can't concentrate; I can't find anything; things are beeping at me all the time and I have no idea where the music is coming from. Ads are telling me I should buy all kinds of things I didn't even know I needed; the temptation to read the news, or email, or the plot of some movie I saw an ad for 20 years ago (but never saw) on wikipedia is too great and another 45 minutes are gone. So I go on ebay and find a VT420 in good condition and buy it; it arrives an unproductive week later, and I hook it up to the serial port on my Linux machine at work and configure getty and login and ... wow, this is terrible! It's just too dang and limiting. And that hum from the flyback transformer is annoyingly distracting. The lesson is that we look back at our old environments through the rosy glasses of nostalgia, but we forget the pain points. Yeah, we might moan about the X protocol or the complexity of SMP or filesystems or mmap() or whatever, but hey, programs that I care about to get my work done are already written for those environments, and do I _really_ want to write another shell or terminal program or editor or email client? Actually...no. No, I do not. So I'm sympathetic to this. I get it. I love the clean simple lines that were the original Unix But this I take some exception to. Yes, the world is more complex, but part of the complexity of our systems is, as Jon asserts, poor abstractions. It's like the recent discussion of ZFS vs merged VM/Buffer caches: most people don't care. But as a system designer, I do. One _can_ build systems that support graphics and networking without X11 and sockets and with a small number of system calls. One _can_ provide some support for "legacy" systems by papering over the difference with a library (back in the day, someone even ported X11 to Plan 9), but it does get messy and you hit limitations at some point. Ted is straddling those lines I'd just like to stress I'm not trying to criticize Ted, or anyone else, really. We've got the systems we've got. But a lot of the complexity we've got in those systems comes from trying to retrofit a design that was fundamentally oriented towards a uniprocessor machine onto a multiprocessor system that looks approximately nothing like a PDP-11. I do agree with Jon that much of Linux's complexity is unjustified (functions called `foo` that call `__foo` that calls `__do_foo_for_bar`...I understand this is to limit nesting. But...dang), but much of it is forced by trying to accommodate a particular system model on systems that are no longer really amenable to that model. - Dan C. I'd argue listen to Ted. He's got the balance. > > --lm > > [1] Truth in advertising, Ted and I are friends, we used to hike together > in Pacifica, we like each other. > > On Wed, Feb 10, 2021 at 11:52:21AM +1000, George Michaelson wrote: > > I won't dispute your age, or how many layers of pearl are on the seed > > Larry, but MP unix was a thing long long ago. > > > > I am pretty sure it was written up in BSTJ, and there was Pyramid by > > 1984/5 and an MP unix system otherwise running at Melbourne University > > (Rob Elz) around 1988. > > > > You might be ancient, but you weren't THAT ancient in the 1980s. > > > > anyway, pearls before swine, and age before beauty. > > > > -G > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm >

I won't dispute your age, or how many layers of pearl are on the seed Larry, but MP unix was a thing long long ago. I am pretty sure it was written up in BSTJ, and there was Pyramid by 1984/5 and an MP unix system otherwise running at Melbourne University (Rob Elz) around 1988. You might be ancient, but you weren't THAT ancient in the 1980s.

On Tue, Feb 9, 2021 at 6:41 PM Larry McVoy <lm(a)mcvoy.com> wrote: David Barak and the OS group as Solbourne wwere able to do it for OS/MP. First as a ASMP kernel where CPU0 ran the unix kernel, but scheduled jobs for all the other CPUs, the as SMP where the kernel could run on any CPU with progressively finer locking on each release. Warner