[TUHS] Macs and future unix derivatives

[Kevin Bowling]

On Tue, Feb 9, 2021 at 7:46 PM Dan Cross <crossd at gmail.com> wrote:
>
> On Tue, Feb 9, 2021 at 9:25 PM Larry McVoy <lm at mcvoy.com> wrote:
>>
>> I'm going to rant a little here, George, this is not to you, it's to
>> the topic.
>
>
> All in all, that was a pretty tame Rant, Larry. :-)
>
>> Who among us is running v7, or some other kernel that we all love
>> because we understand it?  I'd venture a guess that it is noone.
>> We like our X11, we like that we can do "make -j" and you can build
>> a kernel in a minute or two, we like our web browsers, we like a lot
>> of stuff that if you look at it from the lens "but it should be simple",
>> but that lens doesn't give us what we want.
>
>
> 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.

This is the realest description of the modern predicament I have seen!

Depending on mood and day, things can be great or awful with modern
software for me.  In particular, we live in a world of total abundance
which is great but also overwhelming.  There are no shortage of
interesting kernels, libraries, and applications all for free which is
particularly amazing having grown up in the brief era of the PC world
where most interesting software was shrink-wrapped and cost
prohibitive.

I can't help but eventually tie the current status quo back to
economics.  There is a lot of (perceived?) power in flexing a large
staff of programmers, whether they are productive or not.  It's like
having a large standing army during peacetime.  The mere existence
gives you power in the current market.  Look at the first 10 companies
on this list https://companiesmarketcap.com/.  It's safe to say Aramco
has top quality HPC and development staff and the rest are all mostly
pure tech plays with large staffs of developers and systems engineers.

So in a way, we are sustaining Full Employment Theory for people with
*nix skills.  That isn't great for quality.  Early OS work was done by
small teams relative to current, people who really cared about what
they were doing.  The modern situation is great for people's
livelihoods, so unless you are retired make hay while the sun is
shining.

> 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 we live in a more complex world.
>
>
> 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
>> and he's doing the best he can and his best is pretty darn good.
>
>
> 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