But worst of all is what they've done
To software that we used to run
Like dbx and even /bin/cc.
Compilers now have license locks
Wrapped up in OpenWindows crocks --
We even have to pay for GCC!
The applications broke;
/usr/local went up in smoke.
The features we've depended on
Before too long will all be gone
But Sun, I'm sure, will carry on
By peddling Solaris,
"Bye, bye, SunOS 4.1.3!
ATT System V has replaced BSD.
You can cling to the standards of the industry
But only if you pay the right fee --
Only if you pay the right fee . . ."
Lyrics by N.R. "Norm" Lunde, The Day that SunOS Died, to the tune of "American Pie."
The operating system of supercomputers
When I was studying math at the University of Illinois, my first year's support was as a teacher's assistant, and my second one, that I was quite happy about, was as a research assistant at the National Center for Supercomputing Applications. I walked in vaguely hoping to work on Cray supercomputers: in fact I worked on successor supercomputers made by Silicon Graphics. And really, the main workhorse computer I was working with had 32 CPU's, which wasn't their most powerful, but today you need to really dig today to find a computer with 32 CPU's even though twenty years have passed since then.
Part of my work was system administration, which covered software installation, updates, and related responsibilities. In addition to this I made one major program that addressed a critical interest. It would run some software in question with different numbers of CPU's, giving flexibility and control in producing a graph that shows at a glance how the program is running at the specified numbers of CPU's. I have no idea why any revision of that program would still be in use today, but one of the extremely pressing questions on the minds of the userbase was, "Is my program scaling the way I am attempting to do to increased CPU's?" and this program succeeded enough to answer that question at a glance.
I considered, and still consider my time there to be a great privilege, and I remember seeing an e-mail offering a privately owned(!) used SGI Octane for $8000. The SGI computers were really something.
However, the OS those computers were tied to was another deal entirely. They ran a flavor of Unix called Irix, and in a social setting where Unix chauvinism was mainstream. I mentioned above that I installed software; that does not usually qualify as evidence of any particularly great skill; on Linux today you can run "sudo apt-get install apache2" and maybe enter a password and everything is neatly tucked away. There might be something substantial going on behind the scenes, but the requisite effort and knowledge to install Apache really just boils down to the command line equivalent to "point and click."
This is not true of the SGI version of Unix called Irix. Everyone I remember dealing with was a Unix wizard, but I do not recall a single person who liked Irix. I remember one person voicing hopes that some would port Linux to run on SGI supercomputers. For an example of what was wrong, and a particularly obnoxious example, read the following:
Introduction Thank you for purchasing InCom's PowerComp Libraries. At InCom, customer satisfaction is our number one priority, and we hope that you will be pleased with the power of our libraries. Please follow all of the instructions in order to enjoy a quick and easy installation. Getting Started In this guide, information which you will need to supply will be enclosed in angle brackets, <like this>. Commands which you will have to enter will be indented, like this. You will need to provide a loading directory, in which to load the material from tape (/tmp/pcl is recommended), and a permanent installation directory (/usr/local/pcl is recommended). Loading From Tape First create and change directory to the loading directory: mkdir <working directory> cd <working directory> Now you are ready to load the software from tape. The specific device name needed to load the tape varies with hardware vendors, and may be found in Appendix A, "Vendors and Device Names". Load the software from tape: tar xvf /dev/<device name> You have now loaded all of the software from tape, and are ready to compile and install the PowerComp libraries. Compiling and Installing the PowerComp Libraries Compiling and installing the libraries is handled by a user-friendly shell script. You will need to provide some information to the script, such as your organization name and registration number. To run the script, type /bin/sh pcl/pcl.install -d <installation directory> Follow the script's directions, and provide the information which it prompts for. When the script prompts you for the directory in which the distribution files are located, you will find that you are unable to provide it with any directory which the script will deem satisfactory... Then spit into the computer's ventilation slots. This will complete different circuits inside the computer, causing its motherboard and cards to function in ways that the engineers never intended, thereby making your system compatible with our libraries. Reboot your computer. The installation is now complete.
(N.B. I posted this and the XEmacs maintainer asked permission to include it under the XEmacs installation instructions.)
This was written after attempting an installation under Irix and finding that I was being prompted for a directory location by a shell script that rejected every single reasonable (and unreasonable) answer I provided. I don't know exactly what the result of that installation attempt was; if I recall correctly, my boss was not the faintest bit surprised that I had extensively offered directories and that no single directory was ever accepted by the installer. The general comment I remember is, "Nothing works under Irix!"
If I may boast a bit, my achievements at the National Center for Supercomputing Applications hold two things that were noteworthy: providing a nifty tool that helped with a major need, and installing basic software under circumstances where the level of difficulty installing something on Irix could be on par with out-stubborning a cat.
I've been involved with several flavors of Unix before and since then; I was in charge of a Santa Cruz Operation Unix lab for a previous position, and I cut my teeth as a system administrator on (4.1.3, BSD) SunOS in high school, as well as Linux distributions including Gentoo (mentality as taken from forum signature: 'Ubuntu: an African word meaning, 'Gentoo is too hard for me."'), which is penny wise and pound foolish in that it allows much tighter optimizations of binaries than anything I know, but regular updates would frequently break, and one used standard investigative skills to search for who found the breakage before you, and what it was that made it work. In other words, the cost of shaving off microseconds or milliseconds off of executing XYZ software was easily an hour a week of your time playing mechanic for random breakage as your computer was kept up to date. And that was after learning specialized search approaches to find pages saying "I had this go wrong and here is how I fixed it or found a workaround."
OSX as a flavor of Unix
For a long time I thought in terms of MacOS being my favorite flavor of Unix. (N.B. My Unixy usage, for instance, included Homebrew for Unix software not available as a regular Mac app, and my two most heavily used applications were Chrome and Terminal, with VMware in third place.) I'd done plenty of easy software installations, and problematic installations as well, and I was content with either. When certain things like installing software became harder, I didn't particularly notice.
However, I did notice when, trying to build up my Mac to function as a server running several useful websites, that it was taking a while to install SugarCRM. And I was caught off guard when web discussion said that Apple had removed certain OS components that SugarCRM tried to run. (Huh?) I opted for a plan B of trying to install SugarCRM on a Linux Mint virtual machine under VMware.
I was astonished at how easy it was, and how much a matter of "Follow your nose." It was the Linux command-line equivalent of "point and click": follow a short, simple set of instructions (if even that), and you have a working software installation in no time. Then I installed one or two additional packages. Again, practically "point and click" difficulty level. These things that I had wrestled with on my Mac, sometimes winning, sometimes not, and Linux Mint cut like a hot knife through butter.
I shifted gears then; I no longer wanted to make the websites (SugarCRM / SuiteCRM, Request Tracker, MediaWiki, etc.) based on my Mac and resort to proxying for a Linux Mint VM for the remainder I couldn't get working on my Mac; I thought I'd make a fresh start on a new Linux VM without any history, and this time through aim to make an appliance that could profitably be offered to others.
Unfortunately, I began this appliance project after installing an update to OSX 10.12.4, and once that update was in place I began to experience multiple daily crashes from every VMware Virtual Machine I tried. Suddenly installing things under Linux was harder than directly on my Mac.
I have admittedly been using a slightly old (7.1.3) VMware Fusion, and I'd consider upgrading it. However, a fresh copy of VirtualBox seems do to predictably well at everything I have tried; an up-to-date VMware Fusion installation is off the critical path for me now.
(I believe that my last VMware Fusion update was after the time VMware stopped cold after an Apple OS upgrade.)
I have narrated above the breakage that shipped to me with OSX 12.2.4; the breakage that shipped with the OSX 12.2.2 update was Terminal.app crashing on a regular basis. And while I don't wish to patronize developers who work with graphical IDE's, the two most heavily used applications I have are Google Chrome and Terminal. When I poked around, I was pointed to an Apple developer bug first posted in 2016 that has 147 "I have this problem too" votes. It's not resolved, and people are advised to circumvent the (immediate) problem by using iTerm2. But I would like to make a point, and again no slight is intended against developers who leverage graphical IDE's like PyCharm:
I have used the Unix / Linux command line for decades, and it is a powerful toolchest to be able to use. While there are of course differences between Linux and MacOS's BSD-based computing environments, I find it quite helpful that my main way of doing Unixy things on a Mac works essentially unchanged on a Linux Virtual Private Server, or shelled in to my father's NetBSD server, or in general being able to work with someone and have full superpowers merely by downloading PuTTY and not making further demands on a Windows box's hard drive and resources. Maybe I would program better if I knew how to really take advantage of a top-notch IDE, but as things stand, I acquired a One Laptop Per Child to serve as a tool for a disabled child, and in following a HOWTO to beef up the laptop to serve these kinds of needs, I was still surprised and delighted when I pulled up a Red Hat command line terminal window and felt, "This speaks my language!" Apple, if anything, is giving cues that it is actively forgetting, if not its Unixy internals, at least Unix guru customers. I wish they had done something more polite to Unix users than breaking and not fixing Terminal, like setting a Terminal.app background image of someone flipping the bird at command-line Unix / Linux types. Really, flipping the bird would be markedly more polite.
That's what broke for the Unix crowd with 10.12.2.
My VMware installation became heavily destabilized with 10.12.4.
I have no idea what is next.
As far as Terminal goes, destabilizing it to some degree would make an excellent move to tell Unix wizards "You're not wanted here," while people using a Mac as it is marketed now, getting powerful software from the hardware store instead of hacking in Python, wouldn't grasp the difference even with extended explanation.
Failing to support mainstream Unix developer interests
More recently I posted another issue: there's something called Apache installed, and I can't do an
apachectl start twice without getting an error of
/System/Library/LaunchDaemons/org.apache.httpd.plist: service already loaded, but I can't for the life of me connect to port 80 on localhost. I posted on apple.SE at https://superuser.com/questions/1185171/how-do-i-get-apache-to-run-from-osx-sierra-10-12-13 :
I've made multiple searches for e.g. "apache Sierra", but haven't been able to find my issue.
I have a MacBook Pro running OSX Sierra 10.12.3, and it seems to have some version of Apache installed, but I can't connect on port 80 (or 443), either with a browser, or by running
telnet localhost 80. If I run
apachectl restart, it runs without reported error; if I run
apachectl stopit runs without reported error; if I run
apachectl startwhen I think Apache is running, it gives an error message,
/System/Library/LaunchDaemons/org.apache.httpd.plist: service already loaded. A
/usr/sbin/apachectl, so I believe I'm running OSX's native Apache and not a version pulled in from Homebrew.
What can/should I be doing so that Apache is running normally?
After the question was old enough to be eligible for bounty, and I had gotten off the phone with Apple technical support, I flagged it for moderator attention and requested migration to ServerFault.
In the technical support call, which lasted a bit short of an hour, I was escalated twice; even the first escalation was with someone who didn't know the command line and didn't know what Apache was. I was told that Apple offers Server which may include Apache, installable from the store, and supported GUI-driven use of Server, but Apple technical support does not offer help for the command line or command-line-driven Apache setup and configuration file editing.
Those both look like significant red flags. It's mainstream for users who want Macs to offer Unix functionality to want a stable Terminal.app and it's mainstream for web developers to want a working Apache installation on their box even if it's not shared.
Now I know that MacOS and iOS, with their
NSStrings, owe a nearly indelible debt to Unix. And there are workarounds, like iTerm2 and Homebrew or source builds of Apache, and I'm using iTerm2 and plan on building another Apache. But I see ominous writing on the wall; it seems that Apple is losing its respect for hackerdom.
Are there other examples or signs that Apple is dropping care for Unix hackers?
"On [date], Apple announced the death of the Mac. And Apple couldn't be happier!"
One article, I read an article about the introduction of the iPad, with a title like, "On [date], Apple announced the death of the Mac. And Apple couldn't be happier!" The announcement of "the death of the Mac" was a reference to the release of the iPad, a device that is giving other devices including the Mac a run for its money. And indeed a basic observation holds: Go to a computer store and ask for a smartphone or tablet, and a salesperson will try to guide you to choosing between a dizzying array of options. Go to a computer store and ask for a desktop PC, and you may get some comment like, "They're out in the back, next to the mainframes."
At the risk of belaboring the obvious, on technical grounds iOS devices are a more purist Steve Jobs-like version of the Mac. Or at least they are as programming goes. As regards physical technology, they represent something that is smaller, lighter, use a touchscreen well (with high pixel density!), and in general more shrewdly adjusted than any laptop or desktop I am aware of, Macs and e.g. MacBook Air's specifically included. But if we bracket the step from movable laptops to mobile iPhones and iPads, and look from a programming perspective, iOS is basically MacOS (if you're in the App store for either, you're using e.g. NSStrings), but stricter and more focused around some UX concerns. There is a command line for iOS devices, developers apparently consider it essential, and my understanding is that a jailbroken iOS device usually unhides it. However, the technical aspects have been corralled, out of heavily Unix-powered, OSX-based tools, to be able to say, "There's an app for that!", and present users with a hand-picked set of offerings in a walled garden. It is technically possible to program your own device, but only if you pay a developer's subscription membership, and one gets the sense that Apple allows people programming own devices as a necessary evil to get a flow of app submissions that will allow regular customers to have every app etc. that Apple would like to be included among the iOS ecosystem. And my own attempts to migrate from a Mac to an iOS devices have been failures, because one window-filling app (even if that app allows remote access to a server's command line) does not support complex tasks with multiple terminal windows with each terminal window doing its own part.
But here is something that I did not hear from Apple being delighted at "the death of the Mac." It is also different related suggestions that XCode could be available to Linux, possibly in order to obviate the need to sell Macs to enable developers to target iOS. My original interpretation was that, over time, iOS device sales would bury MacBook sales, as mobile sales seem to everywhere be burying laptop sales. And that may have been all that a journalist writing a punchy headline really meant.
But what I've observed is different. Unix wizards seem to be less and less welcome to use Macs as offering a very nice consumer OS with all the comforts of $HOME. We're being kicked out, or at least there are clearer and clearer hints to go away. Allowing Terminal.app not to remain broken, and (AFAIK) not even steering people to iTerm2 when developers ask for any workaround, is a step beyond how institutions like Barnes & Nobles would play classical music that on some counts was used to subtly tell teenagers that they were not welcome to hang out. Frequent Terminal.app crashes are not in any sense subtle; they create a hostile environment to customers who want the Unix command line without perturbing general public customers who will in all likelihood not know what a Unix command line is.
Top-notch iPads are being sold as "Super. Computer."s, and OSX's progressive Unix breakage is starting to seem like the supercomputer OS I used, Irix. I grew up with Ultrix, and I've had exposure to more flavors of Unix than I can remember, and more Linux distributions than I can remember, and Gentoo and Sierra 1.12.4 have together done the best I've seen yet to give nasty Irix a run for its money. During the time, I have done software installations that would succeed without further attention after a "brew install _____" or "aptitude install _____". I've also done installation-driven research investigations that rival outstubborning a cat as far as difficulty goes. I hadn't really noticed how many attempts to get something working under OSX included repeated web searches, or how many immediate approaches had been failing, until I went to a Linux VM to try and see if I could install SuiteCRM, and encountered a difficulty one notch above "point and click," not more. I don't remember if I was given installation instructions, but if there were, they were short, they worked the first time, and they were unobtrusive enough that I've forgotten them completely.
The more installments complete coming in, the more it looks like the Unix side of OSX is turning into Irix.
This article was posted while I did not know where my iPhone was. For the second time since acquiring this iPhone 7, I have lost it and been unable to locate it by usual means, such as calling my iPhone from another line and should have heard vibration, although I believe it is in the house as my iPad is proxying phone calls to my iPhone and sound is crisp and clear. My Apple ID password is locked in my iPhone password manager (my fault; I should have been using redundant password managers from the beginning), and so I can only look up my password to use Find My iPhone if I track down and use my iPhone. There is only one recovery option driven by a manual anti-fraud investigative process on Apple's end, and it's been a couple of days since I attempted to exercise that option. I called Apple technical support and after a couple of dead-end calls spent a fifteen or twenty minute call with a tech support person who checked in with her supervisor and explained that, because I had requested some days before to recover Apple ID account access, that she was not allowed to do anything to change my password or otherwise let me in. I asked about an ETA for my multi-day password recovery, and simply was not provided with any estimate of any sort even though I had a good rapport with the technical support representative and she tried to give me practically everything she could.
There is no one for shiny gadgets like Apple, although I gave my Apple Watch to my brother because I thought he'd genuinely like the "Mickey Mouse watch" bit and I found that the watch I thought I could program was on a device that didn't even have a web browser. I'm not saying I couldn't enjoy a programmable Android watch, but I am right now happy to have a 20bar water resistant compass watch (not a smartwatch) to take to my adventures. Right now the brand is appealing to me less and less.