#UNIX is not just an OS; it is arguably the ultimate #IDE for #programmers. Arguably the best written introductory book on UNIX programming is "The UNIX Programming Environment", Kernighan (1983). This book covers UNIX V7, but I used it with 4.2BSD.

There is another jewel of a book of a similar kind, a free one to boot, by Prof. Ballesteros (King Juan Carlos University): "Introduction to Operating Systems Abstractions Using Plan 9 from Bell Labs" (2007). Prof. Ballesteros wrote this book to teach his CS students the fundamentals of good OS design.

Although almost no one uses #Plan9 today, it is alive and kicking. It even runs on Raspberry Pi. Anyone interested in OSs and likes the philosophical underpinnings of UNIX should take a look at Plan 9.

The other must-read book is his "Notes on the Plan 9 3ed Kernel Source" (2007). It is a Lions-style commentary.

Prof. Ballesteros has many Plan 9 related publications in PDF format.

https://lsub.org/books-papers/

PS—Those with a historical bent should also read Organick's "The Multics System: An Examination of Its Structure" (1980). Multix is the mother of UNIX, and Plan 9 is the grown-up UNIX.

Books and papers

These are some publications and books I wrote. They are arranged on sections depending on the system they refer to, or put in the miscellaneous section if they do not refer to a particular system w…

Fran. J. Ballesteros
@AmenZwa agreed. part of The Unix Way, imo, was that any terminal provided a de facto IDE. you just have to learn the various CLI tools and shell patterns and common keystrokes etc. I think the more modern trend of ostensible IDEs made more sense in reaction to what MS Windows and early Mac gave a programmer out of the box. if you can already get what you need they appeal less

@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

How deep is the pond?

And I shall have to look it up how heavy a PDP-7 is.

@AmenZwa @dougmerritt @rl_dane @raven667

@vnikolov
Apparently, the pond is deep enough, unlike the shallow ones found at typical tRUMP property, say the Lincoln Memorial Reflecting Pool. So, you’d need my assistance. I claim 49%, including finder’s fee.

We can retire to Mars with the proceeds. I’m imagining throngs of old, long-bearded UNIX geeks trampling over each other’s canes and walkers to get in on the action to possess such a massive (in many senses of the word) piece of the history.

@dougmerritt @rl_dane @raven667

@AmenZwa
> each other's cains

I'm going to insist you mean 'cairns', as in, "over my dead body".

That seemed to me a decent idea up until I found out Musk would be there.

@vnikolov @rl_dane @raven667

@dougmerritt
Thanks again for another spelling correction.😀

@vnikolov @rl_dane @raven667

@AmenZwa
Think nothing of it. We owe it to each other, in these trying times.

@vnikolov @rl_dane @raven667