@synlogic4242
Of course, it is a bit unfair for us "moderns" to compare UNIX to the likes of NeXTSTEP, Windows, macOS, and such. This comparison came about, because UNIX, starting in the early 1980s, began competing in the PC market, and soon gave birth to the workstation OSs of the time: SunOS, IRIX, Ultrix, AIX, HP/UX, and so on, sporting the X Window System. But despite all those modern accoutrements, UNIX was still very much the 1960s time-sharing OS, not a personal OS. That heritage continues into the modern UNIXen, like FreeBSD, NetBSD, OpenBSD, and Darwin.

Looking upon UNIX in its period-correct context—during the late 1960s and the early 1970s when batch processing on mainframes over the teletype is the fashion of the day—what Thompson and Ritchie achieved in such a short time frame is, frankly, a superhuman achievement.

I do not recall the exact phrase, but I once read something like this in a Bell Labs publication: "UNIX was created by programmers for programmers to do programming". In other words, Thompson created UNIX to make his daily programming activities more efficient, effective, and enjoyable.

UNIX, therefore, is the world's first IDE. By "IDE", I do not refer to modern, surface-indicia of programming, such as buttons, scroll bars, and menus; I mean a unified, coherent system designed, ab initio, to serve as the ultimate software development environment, integrating all programming-related tools that a programmer would need.

In contrast, most popular operating systems (OS/360, VAX/VMS, Windows, macOS, etc.) are designed for non-techie business users.

@AmenZwa
> most popular operating systems (OS/360, VAX/VMS, Windows, macOS, etc.) are designed for non-techie business users.

Abbreviated like that, it is arguable. Expanding the wording:

> most popular operating systems (...) are designed for *applications* aimed at non-techie business users, not at programmers.

...is more bullet-proof, I think.

And it immediately implies the fundamental problem: the app makers are therefore largely not eating their own dogfood. This causes problems that have been widely explored.

@synlogic4242

@dougmerritt @AmenZwa @synlogic4242

> And it immediately implies the fundamental problem: the app makers are therefore largely not eating their own dogfood. This causes problems that have been widely explored.

I honestly feel like we have a reverse problem: the app makers don't actually understand computers or user interfaces, and the people who designed the original GUIs and knew the WHY behind everything have left or retired.

Like, I'm an affable guy. I don't like harping on #UIDesign all the time.
But our modern UI Design is absolute dogshit, if you'll forgive a little vulgarity (fairly rare for me).

It's bad enough that everything is created with 23-year-old eyes in mind, but even basic usability has suffered dramatically in the past fifteen years.

If I had a money tree and a fountain of youth, I'd go back to Uni (AGAIN 🤣) actually get my C.S. degree, and major on UI Design and be the most annoying forking UI Gadfly in all the nine realms.

@dougmerritt @AmenZwa @synlogic4242

Regarding modern UIs, I will say that I'm very happy that search has won over hierarchical menus in general*, particularly for launching applications. I love dmenu/rofi/wofi/fuzzel and even KRunner when I'm on my work machine.

When digging through work folders that are synced with the cloud and have hundreds of thousands of files (in well-organized, but still deeply nested directories), I have my own search menu system I came up using just simple old find, grep, and zstd which is actually faster and more reliable (and much, much less resource-intensive) than the search facilities provided by Gnome or KDE and their complicated daemons and databases.

* I don't mean "hamburger menus" vs. hierarchical menus, though. Those are for the birds. 😄

@rl_dane
I've been doing a bit of thinking out loud (very loudly), of late, about TUIs.

Half-jokingly, I have said, the modern user is so habituated to the text-based interaction with the computer, thanks to the almighty LLM, that it is high time for us oldies to sneak in the traditional TUIs into this generation of users's desktops.

The non-joking half is this. Modern TUIs have got so sophisticated that they now have their own unique aesthetics. Yet, they can be programmed in the same way that were done with the 1970s and 1980s TUIs. No remote calls, no async/await, etc. Some of them even have web browser integration.

Most line-of-business web apps today are used by a handful of in-house business experts only; there is absolutely no need for them to use React, Angular, and other massive web GUI frameworks. The only reason these web apps came into existence is the in-house coders wanted to get those frameworks on their resumes, so they can go work at the Big Tech.

@dougmerritt @synlogic4242

@AmenZwa @dougmerritt @synlogic4242

I'm impressed with what creatives can do with web apps, but when I have to use them for work, I cringe.

Like, a JS-heavy thing for creating music or procedural art? GRAVY

A JS-heavy thing for me to check my bank account? "Calgon, take me awaaayayyy..." 😂

I remember using TUI-and TUI-like GUIs (very, very text-heavy GUI database applications where there really wasn't enough room on a 640x480 or even 800x600 screen to waste space on much of anything but TEXT) in the 90s, and they were so efficient.

To this day, I'm still running a nearly decade-old version of an accounting application at work, because I just will NOT muck with the horrid web apps. If you see me using this old desktop program (via VNC, 'cause boyo ain't running windows on his own machine!! 😆), I'm absolutely flying through screens and menus; I have every major screen memorized and know exactly how many times to hit TAB to move from the addressee to the date field, to amount, category, memo, class, then enter, enter and on to the next thing.

If I had to use a web application for that, you'd have to put me on suicide watch. 😂

But I've actually been learning and using ed recently. For all its limitations, there s a very Zen feeling when editing text in ed, which isn't even a TUI. It is (as I'm sure all here know) an editor that would work on a terminal as dumb as the Apple I.

My only complaint with TUIs is that they lack the shared keybinds and consistency of early GUIs. Some are very vi-like or even less-like, but others are more bespoke. Going from vi to less is easy, then less to a web browser like lynx, w3m, or cha. But links/links2? Totally different keybinds, and not configurable. urgh.

Some kind of committee thing to come up with interaction standards for TUIs would be golden. Some are very intuitive, like the fedi client I use, @[email protected]. Others require a bit more learning to get comfortable with, like iamb, the Matrix client.

I often think back to the Apple Macintosh project, and Jef Raskin, who wanted to make it a text-based, and keyboard-driven system. I would have liked to see what his ideas were like, because I think it would've been a neat midpoint between the user-friendliness of modern-ish GUIs, and the sheer power of a nicely-designed interactive Unix program (TUI and not-quite-TUI).

@rl_dane I work with the kind of internal web apps you are talking about, and I'm not sure a TUI framework (the Borland one was recently open sourced and ported to Linux, right?) Is better than plain HTML. As said earlier, you dont need JS frameworks like React or Angular, those are really only appropriate for a very narrow use case, but simple HTML forms and CGIs are dead easy to understand the whole stack and pretty easy to make usable/accessible just using the built in elements with a light smattering of plain JS and CSS for interactivity and style.

There was (is) a very influential IBM TUI HIG that most TUI DOS apps comform to, as well as Windows and Motif, but which has largely fallen by the wayside as it isn't taught to new devs and isn't part of the web platform, the web just has raw tools that you can do anything with, but doesn't enforce much. I'm pretty sure you could make a webapp with the same kind of interaction as your TUI, but there isn't a sufficiently influenced force encouraging good, standard UI.

I'm not sure what those guidelines might be or how to encourage it to exist and be adopted..

@AmenZwa @dougmerritt @[email protected]

@raven667 @AmenZwa @dougmerritt

Honestly, using firefox extensions like "Vimium C" makes plain HTML a delight to use from just the keyboard.

The thing that's driving me nuts lately is that some framework-built buttons can't be searched for, and some can't be activated by vimium. They have to be found visually, and clicked on with the mouse alone.

It's so ridiculous.

@rl_dane @raven667 @dougmerritt
I once complained bitterly against the misuse of XML as a programming language (with Turing-complete extensions, of course). Then, the father of XML (Jon, who's on Mastodon), politely chimed in, saying XML was never designed to be a programming language. It most certainly was not. The original designers, like Jon, took inspiration from TeX, SGML, HTML, etc., and made something that was perfect for typed data exchange for the web era. But what do web kids do with it? They use it to store a couple of lines of configuration settings, or to create a full-fledged programming language that no human could read.

Then, there is HTML. Just like TeX and SGML before it, it is a marvellous little declarative markup. Tim designed it to share pre-print peer-reviewed papers with his colleagues. The OG arXiv, as it were. What do web kids do? They turned it into a quagmire of a GUI that culminated in Angular, React, Svelte, Elm, Ember, ..., the list that never ends, with at least three or four more JavaScript frameworks coming out every night.

Back in the 1980s, we had two-year major release, one-year minor release, and quarterly fix releases—on just about everything, from compilers to OSs to applications. That was a sustainable release engineering practice. Today's AI-infused CI/CD pipeline is inhumane (and inhuman).

I kept coaching these kids to be simple, short, sweet, and silent (as in think, don't talk; if you must talk, be sweet, short, and simple), when they design systems, both hardware and software. But the first thing they do is get on LinkedIn and either bragged about their work or ask for help. My goodness!🤦‍♂️

@AmenZwa @raven667 @dougmerritt

When weekly system updates reach into the gigabytes (compressed) download size, something is seriously fubar.

@rl_dane
I say, aren’t we well past weekly patches, what with AI-driven CI/CD pipelines and such?😆

@raven667 @dougmerritt

@AmenZwa
I don't know about *you*, chum, but *my* software knows how to patch *itself*. While it's running.

@rl_dane @raven667

At 20 W of power consumption.

@dougmerritt @AmenZwa @rl_dane @raven667

@vnikolov @dougmerritt
We can’t have the AI data centres consume all the electrical power; the real-time embedded community has to rise up and take back some of that power. We may well be consuming sub-mW individually, but we are hundreds of billions strong and we’re everywhere.

Come to think of it, if the embedded engineers were to follow the practices of the web world, each “embedded” device would now be the size of a refrigerator, and would consume 100 W or thereabouts.

@rl_dane @raven667

@AmenZwa
You can still get PDP-8s with a hefty 4 KB core memory on the used market.

@vnikolov @rl_dane @raven667

@dougmerritt
😆👍Maverick move—again!

By the way, I heard, years ago, an apocryphal story: it is said that the CSRC staff gave Ken’s old PDP-7 a fitting burial at sea (in the pond in front of the Holmdel HQ building), instead of sending it to the scrap yard. But I didn’t see that in Brian’s UNIX memoir, so it’s probably just that, a legend.

I tell ya mate, I was this close to getting that PiDP-11 replica kits, were it not for my wife’s meaningful look….

@vnikolov @rl_dane @raven667

@AmenZwa
Tell your wife she's beautiful, rub her tired feet, and order away!

I hope that PDP-7 story is apocryphal, it would be a great museum piece.

Circa 1980 a friend of mine had some random PDP-8 he used as a footrest, occasionally kicking it to break off some more of those whatchamacallit nifty DEC toggle switches.

I had no particular love (nor experience) of the PDP-8, but I was still shocked. 😱

However others I've told that story said that it was no more than the PDP-8 deserved, that it had brought it on itself. 😝

@vnikolov @rl_dane @raven667

Right!

You all have surely seen this definition:

hardware:
that part of a computer system which can be kicked.

***

Barely tangential, the following doesn't seem apocryphal to me:
at Los Alamos during the Manhattan project they had the most expensive doorstop in the world.

They measured neutron absorption of several different materials.
That included a large piece of gold, which became a doorstop, as it wasn't needed for other scientific or engineering purposes afterwards.

@dougmerritt @AmenZwa @rl_dane @raven667

@vnikolov @dougmerritt @AmenZwa @raven667

> hardware:
> that part of a computer system which can be kicked.

That definition would have helped me a lot as a kid. I asked my dad what the difference between hardware and software was, and he said, "hardware is hard, software is soft." 😂

👍🙂

From the same fortune file:

Lizzie Borden took an axe
And plunged it deep into the VAX.
Don't you envy people who
Do the things you want to do?

And to end on a positive note:

A Unix saleslady, Lenore,
Likes to work, but she likes to play more.
So she found a good way
To combine work and play
And she sells C-shells by the shore.

#Limerick

@rl_dane @dougmerritt @AmenZwa @raven667

@vnikolov @dougmerritt @AmenZwa @raven667

Haha, that last one is fantastic.

I did technically start my unix journey in csh, but I didn't really know what I was doing then.
When I started really learning shell scripting, it was with ksh, which translated easily into bash. I've now taken to writing POSIX shell more quite recently, as it can target both Linux and the BSDs without requiring an extra install on either.

But I do wonder what csh would have been like. I never did mess around with it, except as a very, very beginning unix user of SunOS in the early 90s. ;)

I used to use csh a lot, many years ago.
Like many others, I suppose, I was particularly happy with its history manipulation features.
They are all in bash now, of course, perhaps in other shells as well.
For example,
$ !?foo?:gs/bar/baz/
(I often prefer to enter a change to a previous command, rather than re-edit the command line, but that is a separate topic.)

As the documentation itself noted, the syntax of csh has "unexpected quirks"¹; for a while I put up with them.
In any case, in those days it offered significantly more than the Bourne shell _in some respects_, if I recall correctly, like expansion of variants in braces.
These features, too, have long been added to bash.

(I never used tcsh.)

_________
¹ This is a quote.
Checking it just now yielded:
csh programming considered harmful
<https://web.mit.edu/ghudson/info/csh.whynot>.
So, yes...

@rl_dane @dougmerritt @AmenZwa @raven667

@vnikolov
The C Shell was indeed lightyears ahead of Bourne Shell. Korn Shell did try, but it just couldn't quite get there. But Bourne Again Shell is where it's at. It was amusing and frightening, at once, to have learned that bash had a massive security hole, for years.

@rl_dane @dougmerritt @raven667

@AmenZwa @vnikolov @dougmerritt @raven667

You should check out mksh some time. It has some very interesting improvements.

@rl_dane
Will do. Much obliged.🙏

@vnikolov @dougmerritt @raven667

@AmenZwa @vnikolov @dougmerritt @raven667

The creator is on fedi: @mirabilos

Expect very spicy takes on Unix and shell scripting (and anything else ;)... he's one of us 🤣

@rl_dane @AmenZwa @vnikolov @dougmerritt @raven667 @mirabilos
mksh is way to mainstream :)

Since IceCreamSandwich Android has used mksh as its shell.
source

@kabel42 @AmenZwa @vnikolov @dougmerritt @raven667 @mirabilos

Huh! I had no idea! :D

@rl_dane
> mksh

Thanks, I'll check it out.

Amen:
> The C Shell was indeed lightyears ahead of Bourne Shell.

Especially interactively; even Stephen Bourne agrees, I've heard him.

Bill Joy was, as usual, very creative about both thinking up *and* adding new features. Some of the rest of us tried our hand at writing shells from scratch, but it was as an exercise that was hard enough in itself, let alone adding features. :)

For some years I used csh quite religiously. It took me a long time to see that it was less ideal for scripting. (Religion blinds one to other paths.)

Not that anything but csh and Bourne shell were available for years.

@kabel42 @AmenZwa @vnikolov @raven667 @mirabilos

@dougmerritt

I've heard similar first-hand stories about Bill, like yours, by those who were at Berkeley at the same time. I faintly recall Kurt recounting how Bill fixed and improved the buggy BBN TCP/IP stack, pretty much overnight. Am I mistaken?

I've also heard Kernighan described how Thompson wrote, or rewrote, complex pieces of software, like compilers and OS algorithms, essentially overnight.

Some guys have all the "Joy", I guess....

Were the folks at Berkeley CS, in those days, mostly cordial or corrosive?

@rl_dane @kabel42 @vnikolov @raven667 @mirabilos

@AmenZwa
Wait, you knew Kurt Schoens, really? He married my ex-girlfriend Polly.

I didn't see Bill "read the spec and implement what it said", but everyone agrees that it was fast, just not literally overnight.

Bill was superhuman, though, so I don't really see a problem with the common story.

Everyone was friendly, except a few exceptions. Eric Schmidt was standoffish and didn't seem to really socialize with anyone, although he was active. There were no remote filesystems in that era, of course, but he still hacked up some code to remote mount a disk in a different building. Over a 300 baud dialup.

At the time it somehow escaped me that he was the Bell Labs author of Lex(1), even though I used it.

@rl_dane @kabel42 @vnikolov @raven667 @mirabilos

@dougmerritt
Oh no, so sorry; I mean Kirk (McKusick). My old age....😀

I don't know Kurt Schoens.

Ah, Schmidty....

Using a VT100 over a 300 baud line made me feel good: it gave me the illusion that, when I programmed in a screen-editor, I was thinking and working at the speed of a computer.🤣

@rl_dane @kabel42 @vnikolov @raven667 @mirabilos

Myself, I reached the conclusion once that unpredictable response time hurts more than low connection speed.

I have been spared from using a bidirectional connection (to a computer) at 300 Baud.
I think the worst that has happened to me was a 1200 Baud synchronous connection for a 3270 emulator on a PC.

@AmenZwa @dougmerritt @rl_dane @kabel42 @raven667 @mirabilos

@vnikolov
I’ve only used the 3270 in the computer centre, and very briefly at that. But I guess it would have been a demanding diva, compared to the basic VT100.

@dougmerritt @rl_dane @kabel42 @raven667 @mirabilos

@AmenZwa
Y'all are casually taking this in stride, as if a remote mount at 300 baud was basically the same thing as a human terminal connection at 300 baud.

It was an impressive tour de force in an era when very few, if any, were doing such things even at vastly higher speeds.

@vnikolov @rl_dane @kabel42 @raven667 @mirabilos

@dougmerritt
I am still reading your post, over a 300 baud modem. I just got to the remote-mounting bit. Hang on.

You're absolutely right; remote mounting protocol that works over a 300 baud line, using the ideas and tools of the era, was indeed a Berkeley-worthy feat.

@vnikolov @rl_dane @kabel42 @raven667 @mirabilos

@AmenZwa @dougmerritt @vnikolov @kabel42 @raven667 @mirabilos

Oh man... I'm using @tut limited to certain baud rates using trickle, and it's completely unusable at less than anything but 9600 baud. It redraws every character onscreen several times per refresh. Infuriating. XD

Ed, of course, is a gem, even at 300 baud. XD

#TUI application developers, please test your programs at forced (low) baud rates!

cc: @sjmulder

@mirabilos @AmenZwa @dougmerritt @vnikolov @kabel42 @raven667 @tut @sjmulder

yeah, jupp has optimisations for low baudrates (especially if you disable “fast status line” or the status line entirely), but nōn-ed is not fun at 300 bps (use bps, not baud… 300 baud can easily be 1200 bps or more)

nvi was actually quite usable at 300 baud once the various statusline options were disabled.

You're right, bps, not baud.