My year-long failure with Linux at home

[Paul Robinson]

And I am in a Unix shell for 99% of the time I am at work.

And whosoever shall be found
Without the soul for getting down
Must stand and face the hounds of hell
And rot inside a corpse's shell
- Vincent Price, Michael Jackson's Thriller

I installed Mint with the front end Cinnamon a year ago. It has utterly failed to be a remotely useable desktop.
...
2) Cinnamon crashes about every other day. This renders doing anything useless and I have to reboot.

Cinnamon let me in
- Tommy Roe, Cinnamon

[Ice Cream Jonsey]

You're not saying a Unix terminal is bad, right? That's where anything worth doing gets done.

[Paul Robinson]

You're not saying a Unix terminal is bad, right? That's where anything worth doing gets done.

We had a sign on the door of the computer room at school: "This is the terminal room, but please don't die in here."

Circa 1978, we were using a Univac 90/60 mainframe, which was an IBM 360 workalike but with enhancements including virtual memory. The operating system, VS/9, was one of the best command-line systems, far superior to IBM's OS/VS1, and included the EDT text editor, the best text editor ever made. I would say most of my time was spent using the editor and a small amount of time issuing commands, because most steps of things to do couldn't be automated as well as you can in a Unix or Unix-workalike shell.

For people on IBM mainframes using TSO, the ISPF editor provided the ability to take the current workspace and submit it as an OS/VS1 batch stream, so you could automate a task instead of manually issuing the commands to set up whatever you needed to do.

Your statement implies that (1) your system does not have a decent text editor allowing you to submit the file you're editing as a spawn task or batch process; (2) your work is so much ad-hoc and non-repeatable tasks that you can't write scripts to automate much of it.

With the capacity to use virtual environments on computers, to encapsulate workloads using Docker and Puppet or Chef (or similar competitors) it should be easy to hive off tasks and throw them at spare (real or virtual) machines as needed. Your comment seems to imply there isn't enough capacity to script activities for better automation.

There is one thing mainframes did well on: the creation of parameterized procedures in batch streams so you could change the arguments as needed on the task, and the ability to start jobs from the editor using the file you are editing. Univac used the "DO" command; IBM used the PROC / EXEC function. Digital (now HP) VAX had DCL which provided very strong job management.

Also, they tended to have better scripting languages than CShell / Bourne Shell / Korn Shell. IBM has a reasonably good scripting facility with REXX but like with everything IBM produced, it tended to be overly hard to use, razor sharp and dangerous.

In Unix and woralikes like Linux using non-X terminal environments, the use of Pseudo Terminals where keyboard keys F1 through F9 - depending on the configuration - could be used to logon to separate shells. Is this used much anymore?

It's a rudimentary batch system but not that good, and even "cron" is lacking in some of the batch features mainframes had - especially non-IBM, competitors had to be superior to IBM to get their foot in the door to try to make a sale - 40 years ago.

I think that the use of rack-mounted and virtual computers such as (and yes, this time I looked it up) Amazon Elastic Cloud, there is some capacity for job processing of workloads but I suspect it's weak.

[Jizaboz]

Informative post, Paul.

I think a big difference between the old days and modern times of computing is that we've got sooo much more crap piled on top of crap than there was even in the early 1990s. It's hard to automate things like building out a full stack in a server instance or VM without a lot of manual trial and error within a terminal. Because it's always "Oh this version of this depends on this other thing that is now outdated and has no package so now you have to install it from the source tarball but that source code needs this other dependency that depends on.." well, you get what I'm saying.

So much BS can be involved with simply getting a game to run in Windows these days. In the DOS days, all you needed was a proper Autoexec.bat and config.sys assuming your hardware met the system requirements on the box.

[RealNC]

Hunting that one magic HIMEM.SYS parameter that makes that one particular game work, is not exactly lacking in the BS department...

[Casual Observer]

Wow, when Paul puts his head to it he's still got some good tech chops and wrote about it in a coherent way. It's kind of a sad waste of materials to not be doing even virtual consulting and to be living on $600/month. Come on Paul, i know you threw in the towel awhile ago but pick it up, do something else with what's left of your life and finish strong!

[Ice Cream Jonsey]

Your statement implies that (1) your system does not have a decent text editor allowing you to submit the file you're editing as a spawn task or batch process; (2) your work is so much ad-hoc and non-repeatable tasks that you can't write scripts to automate much of it.

Was that directed to me? I have been employed at various places as a Senior Automation Engineer for the last 10 years. I don't know what is reality and what isn't any more, so it could be that you were directing that to someone else.